Journal of
Accounting Education
J. of Acc. Ed. 22 (2004) 131–152
www.elsevier.com/locate/jaccedu
Hands-on training in relational database concepts Jeffrey S. Zanzig a
a,*
, Bor-Yi Tsay
b,1
College of Commerce and Business Administration, Jacksonville State University, 700 Pelham Road North, 100 Merrill Hall, Jacksonville, AL 36265-1602, USA b Department of Accounting and Information Systems, School of Business, University of Alabama at Birmingham, BEC 306C, 1530 3rd Avenue South, Birmingham, AL 35294-4460, USA Received 1 April 2003; received in revised form 1 April 2004; accepted 1 April 2004
Abstract Accounting has often been criticized for providing summarized information that satisfies only a limited number of information views. Relational database models can facilitate the collection of an extensive amount of disaggregated data beyond what is available in the traditional accounting model. The ability to query the database provides the decision maker with more types of information, while avoiding the overload that can occur when too much information is presented that is irrelevant to the decision process of a certain group. This article presents a simple hands-on illustration in Microsoft Access that can be used in accounting courses to provide students with the fundamentals of using the relational database model in meeting the information needs of organizational decision makers. Ó 2004 Elsevier Ltd. All rights reserved.
1. Introduction Accounting has long been criticized for providing a view of information that is limited in scope and received too late to be of much value. Sorter (1969) criticized the traditional accounting approach as being unnecessarily restrictive and incapable of satisfying the information needs of different user groups. Because of its ability to collect disaggregated data and provide tailored information for individual users,
*
1
Corresponding author. Tel.: +1-256-782-5782; fax: +1-256-782-5312. E-mail addresses:
[email protected] (J.S. Zanzig),
[email protected] (B.-Y. Tsay). Tel.: +1-205-934-8821; fax: +1-205-975-4429.
0748-5751/$ - see front matter Ó 2004 Elsevier Ltd. All rights reserved. doi:10.1016/j.jaccedu.2004.04.002
132
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
relational database models have received widespread attention in accounting as a means of providing many types of information in a timely manner. This article provides the accounting educator with a tool to teach students database concepts through the actual construction of a database capable of satisfying a variety of information views. McCarthy (1979, 1982) argued that the traditional accounting model aggregates data to the point that there is a loss of too much pertinent detail. Since McCarthy (1979) introduced Chen’s (1967) entity-relationship (E-R) design process to accounting, the database accounting literature has demonstrated a broad acceptance of the idea (Dunn & McCarthy, 1997). Researchers argue that the relational database design provides a means of data organization that is effective in meeting the decision support needs of the information customer. This may be attributed to the ability of a relational database to collect and query many important types information beyond just the monetary amounts of transactions. This article provides the accounting educator with a simple and practical example of the relational database design that can be used in the classroom. The illustration begins by taking students through the process of REA modeling. This approach shows how tables of data can be derived and linked to provide an efficient and effective relational database model. This is followed by an application in Microsoft Access through which students obtain hands-on experience in the creation of database tables, the establishment of table relationships, populating the database tables, and the development of queries that can serve as the foundation for various management reports. The example presented in this article helps accounting students gain an appreciation of the capabilities of a disaggregated database of organizational information. Through a hands-on exercise, students obtain practice in the design and construction of a simple and disaggregated database that can be used to meet the needs of information customers beyond what is possible in the traditional accounting model. 2 Although the relational database model in this article is kept small for sake of simplicity, the theory and presentation of a hands-on application provide the foundation for the development of more complex models.
2. The steps of REA modeling It is imperative that the data in a relational database be properly separated into a set of database tables that are appropriately linked together. The REA model guides the database designer by identifying the entities that should be included in the database and determining how to structure relationships among database entities.
2
The traditional accounting model mentioned here is the one based strictly on a system of debit and credit journal entries that primarily collects data regarding the financial aspects of transactions for purposes of aggregation into a set of financial statements.
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
133
2.1. Identify the entities using the REA framework Database entities fall into the three distinct categories of resources, events, and agents. Thus, the technique is known as REA data modeling. The revenue model being developed in this article contains the following entities: 1. Services are the resource that the accounting firm offers to the public. 2. Revenue Transactions occur as the event in the model. 3. Customers and Accountants are the agents associated with the revenue transaction events. A separate entity for accountants is not considered because the model in this article assumes a single accounting firm with only one accountant. 2.2. Identify the relationships among the entities Relationships among entities are defined in terms of cardinalities that show how many instances of one entity can be related to a specific instance of another entity. The following format is typically used: Entity 1 (minimum, maximum) $ (minimum, maximum) Entity 2 3 The following discussion explains the relationship cardinalities among the entities for the model developed in this article. The relationship cardinality between Services and Revenue Transactions is represented as: Services (1; N ) $ (1; N ) Revenue Transactions. The term ‘‘Services (1; N )’’ tells the reader that a single transaction or invoice in the Revenue Transactions entity involves a minimum of at least one service and a maximum of many of the services in the Services entity. Similarly, the term ‘‘(1; N ) Revenue Transactions’’ tells the reader that a single service in the Services entity is associated with a minimum of at least one and a maximum of many transactions or invoices in the Revenue Transactions entity. The relationship cardinality between Revenue Transactions and Customers is represented as: Revenue Transactions (1; N ) $ (1,1) Customers. The term ‘‘Revenue Transactions (1; N )’’ tells the reader that a specific customer in the Customers entity is associated with a minimum of at least one and a maximum of many transactions or invoices in the Revenue Transactions entity. The term ‘‘(1,1) Customers’’ tells the reader that a single transaction or invoice in the Revenue Transactions entity involves a minimum of at least one and a maximum of only one customer in the Customers entity.
3 Many database designers show the minimum and maximum of a single instance of Entity 1 in regard to its possible number of occurrences in Entity 2, by placing the amounts next to Entity 1, and vice versa. Other designers use a reverse of this notation by showing the minimum and maximum of a single instance of Entity 1 in regard to its possible number of occurrences in Entity 2, by placing the amounts next to Entity 2, etc. Microsoft Access shows only the maximums and uses what has been just described as the reverse notation. This article adopts this reverse notation in order to be more consistent with what is shown in Access.
134
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
2.3. Draw the REA diagram The format of the REA diagram may follow the procedure of using separate columns for Resources, Events, and Agents. Rectangles are used to represent the entities. Entity relationships are illustrated with relationship cardinalities that are shown on both sides of a diamond that describes the relationship between the entities. The REA diagram therefore identifies the appropriate entities and theoretically establishes the relationships for the linking of the information that the entity tables will contain (see Fig. 1). 2.4. Determine the attributes for each entity table A diagram similar to the REA diagram, known as an entity-relationship (E-R) diagram, is used to illustrate additional design components; including entity table attributes, primary keys to uniquely identify information in each table, and the use of foreign keys and relationship tables that serve as logical links among tables allowing a single query of information contained in multiple entity tables. For example, the Services table will contain attributes for the Service Name and Hourly Rate for the services that are offered. The Revenue Transactions table will contain attributes for the Invoice # and Transaction Date. The Customers table will contain an attribute for Customer Name (see Fig. 2). 2.5. Determine the primary key for each entity table Each table in a relational database must contain a primary key that consists of an attribute, or set of attributes, that uniquely identifies each row in the table. Numbers are commonly used since text names are rarely unique. The Invoice # serves as the primary key in the Revenue Transactions table. New primary key attributes for Customer # in the Customers table and Service Type # in the Services table will be created to uniquely identify each row in those tables. These primary key attributes are shaded in Fig. 2.
RESOURCE
EVENT
AGENTS
Participant
(1,1)
Customers
(1,1)
Accountant
(1,N) Services
(1,N)
Revenue Trans. Lines
(1,N)
Revenue Transactions
(1,N)
Participant
Fig. 1. The REA diagram for the database.
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
135
Fig. 2. The entity-relationship diagram for the database.
2.6. Establish relationships between tables with foreign keys or relationship tables This step establishes relationships between database entities. Entity relationships are often expressed in terms of the maximums of the cardinality. The maximum of the cardinality between the Customers and Revenue Transactions entities is a oneto-many (1:N ) relationship. This is most efficiently implemented by making the primary key of the ‘‘1’’ side of the relationship a foreign key attribute in the entity representing the ‘‘N ’’ side of the relationship. A foreign key is simply the primary key of a table that is placed in another table strictly for purposes of linking the tables. Therefore, a Customer # attribute will be added to the Revenue Transactions entity (see Fig. 2). The maximum of the cardinality between the Services and Revenue Transactions entities is a many-to-many (N :N ) relationship (see Fig. 1). The relationship between entities in a many-to-many relationship is operationalized by creating a separate entity that links the two entities. This new Revenue Transaction Lines entity will contain a composite primary key value that consists of the primary keys of the tables it links. Therefore, its table will contain attributes for Invoice # and Service Type # (see Fig. 2). 2.7. Determine any additional attributes required for the entity tables The entity created to link the Services and Revenue Transactions entities will need an additional attribute hours worked (Hours) in order to calculate the revenue resulting from providing services. The Hours attribute is logically located in the
136
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
Revenue Transaction Lines entity since both the Invoice # and Service Type # are necessary to relate the hours to a specific transaction. The Revenue Transaction Lines entity is the only one with both of these values (see Fig. 2). 2.8. Evaluate the design An anomaly is a potential problem in the structure of a database that can result in incorrect and/or incomplete information being queried from the database. Fig. 3 shows the design of a sales journal format for revenue transactions that is based on the traditional accounting model. The figure illustrates the following basic types of anomalies that can occur when an information database is not properly designed. 1. Update anomaly – can occur when the value of a data item must be changed and the item is not changed consistently on each line on which it appears. For example, changing the names of customers or services could result in an update anomaly if names are not changed consistently. 2. Deletion anomaly – can occur when a transaction entry containing the last occurrence of a data item is deleted. For example, service or customer information could be completely lost if the last transaction entry containing this information is deleted. 3. Insertion anomaly – can occur when an item cannot be added to a database, until a transaction with information about this item occurs. For example, service or customer information cannot be entered until a revenue transaction involving information about the service or customer occurs. These anomalies, each illustrated in Fig. 3, are resolved by appropriately separating and linking information in a relational database. A review of Fig. 2 indicates that the anomalies described above are resolved when customer and service information are shown in their own respective entity tables. This is accomplished because customer and service information is shown only once in their respective tables, and the tables are then linked to the revenue transactions.
REVENUE TRANSACTIONS Invoice # 101
Transaction Date 1/5/2003
102 103 104
1/28/2003 2/10/2003 2/18/2003
105
2/25/2003
106 107
3/5/2003 3/9/2003
Service Type # 1 3 4 4 1 3 1 4 5 1 4
Service Name Bookkeeping Partnership Personal Personal Bookkeeping Partnership Bookkeeping Personal Tax Planning Bookkeeping Personal
Hours 6 25 6 4 20 35 8 16 5 151 6
Hourly Rate 25 50 40 40 25 50 25 40 75 25 40
Fig. 3. A revenue entry table.
Amount 150 1,250 240 160 500 1,750 200 640 375 3,775 240
Customer # 251 251 136 200 257 257 102 102 102 385 154
Customer Name Stinson & Assoc. Stinson & Assoc. Jack Randall Judy and June Warren Cleaning Warren Cleaning Bernie Contrell Bernie Contrell Bernie Contrell Kirk Company Amy Holt
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
137
3. The creation of tables This section illustrates how to create the four tables used for the database. When Microsoft Access is opened, the user is presented with options for creating a database or opening an existing file. This project will create a new database using the Blank Database (or Blank Access database in Access 2000) option. After selecting this option and selecting the OK button, the user is given a screen to name the database and select where to save it. Change the file name to an appropriate name (this illustration will use the name Accounting), and designate where you want the database to be saved. The Create button can then be selected. The process of creating tables begins by selecting Tables in the Objects bar, and double-clicking Create table in Design view as demonstrated in Fig. 4. This action brings up a screen that allows the user to enter names for the data fields of the table. This procedure should be followed each time a new table is created. In the following discussion regarding the creation of database tables in design view, some data fields will be created using a Lookup Wizard that provides a dropdown menu system in the datasheet view that is later used for data input. The Lookup Wizard should only be used for creating those data fields for which this feature is specifically discussed. 3.1. The services table The first table to be created is for the types of services that the accounting firm offers. This table will consist of fields for the Service Type #, Service Name, and the Hourly Rate that is charged for that type of service. The set-up information for data fields is represented in design view by rows defining the data fields that will appear in the table. The same data fields are presented as columns in datasheet view. The underlying data are maintained on datasheet tables. The database creator should be careful to realize that the design view for table creation only serves to provide the information to create a table. Fig. 5 is a design view that shows the Field Name, Data Type (selected from the drop-down menu that appears when the curser is in this column), and Description that should be entered for each data field. Field properties (not shown in Fig. 5) appear at the bottom of the design screen for each of the rows of information
Fig. 4. Creating a table in design view.
138
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
Fig. 5. The design of the services table.
entered. Default property values should be accepted for each of the tables in this database. Once the information is entered, the table must also designate a primary key that will serve to uniquely identify each row of information that will eventually be entered in the table. This is accomplished by clicking anywhere on the desired row of information for the table data field that will represent the primary key, and pressing the primary key button (key symbol) on the toolbar menu. This procedure will be used for each table in the database. This table will designate the Service Type # field as the primary key. Designating a field as a primary key will place a key symbol to the left of the row describing the data field. The table should then be saved by selecting File and Save As from the toolbar menu, renaming it as Services, and saving it as a table. The design screen for table creation should then be closed by clicking the lower ‘‘X’’ symbol at the upper right corner of the design screen window. 3.2. The customers table The second table to be created will be for the individual customers that are served by the accounting firm. In design view, this table will consist of rows for the Customer # and Customer Name. Fig. 6 shows the Field Name, Data Type, and Description that should be entered for each data field. Once the information is entered, the Customer # should be designated as the primary key that will serve to uniquely identify each record that will eventually be entered in the table. The table should then be saved by selecting File and Save As from the toolbar menu, renaming it as Customers, and saving it as a table. The design screen for table creation should then be closed.
Fig. 6. The design of the customers table.
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
139
3.3. The revenue transactions table The third table to be created will be the Revenue Transactions table. The Customers table must be created before creating the Revenue Transactions table because the Customer # field of the Revenue Transactions table will have a drop-down list of customer information that will be facilitated through a lookup of entries in the Customers table. In design view, the Revenue Transactions table will consist of rows for the Invoice #, Transaction Date, and the Customer #. The Invoice # and Transaction Date rows in the Revenue Transactions table may now be created. Fig. 7 shows the Field Name, Data Type, and Description that should be entered for each data field. The Invoice # field is designated as the primary key in the Revenue Transactions table. The Customer # row can be created by entering Customer # as the field name. Next, invoke the Lookup Wizard from the drop-down menu that appears when the curser is on this field’s column for Data Type. The Lookup Wizard will proceed through a series of screens to establish the relationship between the Revenue Transactions and Customers tables. Table 1 summarizes the entries necessary for the Lookup Wizard. The reason for using the Lookup Wizard is to create a drop-down menu feature for the user of the database when data is later input in the datasheet view. While inputting customer data into the datasheet view of the Revenue Transactions table, this feature will provide the user with a drop-down menu listing of customer information (Customer # and Customer Name) for each customer as shown in the Customers table. Before exiting the Lookup Wizard and establishing the relationship between the Customers and Revenue Transactions tables, Microsoft Access will request that the table be saved. This question should be answered ‘‘Yes’’ and the table saved with the name Revenue Transactions. Once this is completed, a description should be entered for the Customer # field. The design view screen for table creation should then be closed. In the process of closing, the program will prompt the user to save the table again. Click ‘‘Yes’’ to save the table. 3.4. The revenue transaction lines table The fourth table to be created will be for the revenue transaction lines for each separate service provided. In design view, this table will consist of rows for the Invoice #, Service Type #, and Hours worked. Fig. 8 shows the completed design of the table.
Fig. 7. The design of the revenue transaction table.
140
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
Table 1 Lookup wizard entries for customers in the revenue transactions table Screen request (summary of prompt)
Selection/Response
Method of obtaining lookup value
Select ‘‘I want the lookup column to look up the values in a table or query’’ Click the Next button
Table or query providing lookup column values
Select Customers Click the Next button
Fields to include in lookup column
Use the double arrow (>>) button to move both the Customer # and Customer Name fields from the Available Fields box to the Selected Fields box Click the Next button
How wide would you like the columns in your lookup column?
Remove the mark in the box next to the ‘‘Hide key column’’ text Click the Next button
Value to store in database
Select Customer # Click the Next button
Label for lookup column
Accept the default label given Click the Finish button
Fig. 8. The design of the revenue transaction lines table.
The Invoice # row can now be set up as shown in Fig. 8. The Service Type # row can be created by entering Service Type # as the field name. Next, invoke the Lookup Wizard from the drop-down menu that appears when the cursor is on this field’s column for Data Type. The Lookup Wizard will proceed through a series of screens to establish the relationship between the Revenue Transaction Lines and Services tables. Table 2 summarizes the entries necessary for the Lookup Wizard. Before exiting the Lookup Wizard and establishing the relationship between the Revenue Transaction Lines and Services tables, Microsoft Access will request that the table be saved. This question should be answered ‘‘Yes’’ and the table saved with the name Revenue Transaction Lines. In the event that Access asks if a primary key should be created at this point, the question should be answered ‘‘No’’. The primary key for the Revenue Transaction Lines table will consist of two data fields that together serve to uniquely identify each record. The primary key can be established by positioning the mouse over the gray
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
141
Table 2 Lookup wizard entries for service type # in the revenue transaction lines Screen request (summary of prompt)
Selection/Response
Method of obtaining lookup value
Select ‘‘I want the lookup column to look up the values in a table or query’’ Click the Next button
Table or query providing lookup column values
Select Services Click the Next button
Fields to include in lookup column
Use the arrow (>) button to move both the Service Type # and Service Name fields from the Available Fields box to the Selected Fields box Click the Next button
How wide would you like columns in the lookup column?
Remove the mark in the box next to the ‘‘Hide key column’’ text Click the Next button
Value to store in database
Select Service Type # Click the Next button
Label for lookup column
Accept the default label given Click the Finish button
box to the left of the row for the Invoice # until a right-pointing arrow appears. Then left-click and hold and drag the mouse over the same area for the Service Type # so that both rows are shaded (selected) before releasing the mouse. With these two rows selected, the primary key button on the toolbar menu can be clicked to select these combined fields as the primary key. Designating these fields as the composite primary key will place a key symbol to the left of the rows describing the data fields. Once this is completed, a description should be entered for the Service Type # field. In addition, the Hours worked field needs to be added to the design (see Fig. 8). The design view screen for table creation should then be closed. In the process of closing, the program will prompt the user to again save the table. Again, although it is not readily apparent in the design view, the reason for using the Lookup Wizard is to create a drop-down menu feature for the user of the database when data is later input in the datasheet view. While inputting service data into the datasheet view of the Revenue Transaction Lines table, this feature will provide the user with a drop-down menu listing of service information (Service Type # and Service Name) for each service as shown in the Services table.
4. Establishing relationships among tables Since a request for information may involve information that is contained in separate database tables, it is imperative for the tables to be linked. For example, customer and revenue transaction information appears in separate tables. A relationship must be established between these tables in order to determine revenue by
142
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
customer. Relationships among tables are established by providing appropriate linking fields, as previously discussed in the steps of REA modeling. This section explains how linking is accomplished and referential integrity is enforced. The process of establishing table relationships begins by selecting Tables in the Objects bar, and clicking on the toolbar button for the relationships screen (see Fig. 9). In most cases, the relationships screen will appear showing each of the tables and some of the preliminary relationships that have been established through the Lookup Wizard during the creation of the tables. In other cases, Access may ask the designer to identify tables to add to the relationships screen. In the event that the relationships screen does not show each of the created tables and/or preliminary relationships, the ‘‘Show All’’ command can be selected from under the Relationships item on the toolbar for the relationships screen. The relationships screen will require some cleanup that can be accomplished by left clicking a table and holding down the mouse button while dragging the table to its desired location on the screen. A table can be resized by moving the mouse along the appropriate edge of the table until a double arrow appears. The left mouse button is then held down while the table is dragged to its desired size. The relationships screen should be modified using table moves and resizing until it appears as shown in Fig. 10.
Fig. 9. The creation of table relationships.
Fig. 10. A preliminary view of table relationships.
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
143
4.1. Services and revenue transaction lines Referential integrity requires an entry for a data field when a record is entered into a table. For example, each entry in the Revenue Transaction Lines table must have a Service Type # entered that points to an existing service in the Services table. Enforcing referential integrity between the Service Type # in the table of Revenue Transaction Lines and the Service Type # in the Services table, requires that the user of the database enter a Service Type # for each row in the Revenue Transaction Lines table. This procedure helps to avoid having revenue entries that are never assigned to a particular service type. Referential integrity can be enforced in the relationships screen area by rightmouse clicking the line that appears between the Revenue Transaction Lines and Services tables to bring up the option to edit the relationship. Selecting edit relationship brings up the screen shown in Fig. 11. In the edit relationships screen, the box to enforce referential integrity should be checked. It is important to note that the relationship type shown on the bottom of the edit relationships screen shows a ‘‘One-To-Many’’ relationship between the Services and Revenue Transaction Lines tables. This means that each revenue transaction line is associated with a maximum of only one type of service. However, each type of service may be associated with a maximum of many revenue transaction lines. Once referential integrity is enforced, the OK button should be selected to close the edit relationships screen. 4.2. Customers and revenue transactions Referential integrity should also be enforced between the Customers and Revenue Transactions tables. This is accomplished by right-mouse clicking the line that appears between the Revenue Transactions and Customers tables to bring up the option to edit the relationship. Selecting edit relationship brings up the screen shown in Fig. 12.
Fig. 11. Enforcing referential integrity between services and revenue transaction lines.
144
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
Fig. 12. Enforcing referential integrity between customers and revenue transactions.
It is important to note that the relationship type shown on the bottom of the edit relationships screen is a ‘‘One-To-Many’’ relationship between the Customers and the Revenue Transactions tables. This means that each revenue transaction is associated with a maximum of only one customer. However, each customer may be associated with many revenue transactions. Once referential integrity is enforced, the OK button should be selected to close the edit relationships screen. 4.3. Revenue transactions and revenue transaction lines The initial relationships discussed above were established by using the Lookup Wizard when creating the tables. One final relationship should now be created by leftclicking and holding the mouse down over the Invoice # field in the Revenue Transactions table. The mouse should then be dragged and released on top of the Invoice # field in the Revenue Transaction Lines table. This step invokes the edit relationships screen for the establishment of the relationship between these two tables (see Fig. 13).
Fig. 13. Enforcing referential integrity between revenue transactions and revenue transaction lines.
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
145
Fig. 14. A completed view of the relationships screen.
Since every line of the Revenue Transaction Lines table is required to relate to an Invoice # in the Revenue Transactions table, the box to enforce referential integrity should be selected. Again, it is important to note that the relationship type shown on the bottom of the edit relationships screen shows a ‘‘One-To-Many’’ relationship between the Revenue Transactions and Revenue Transaction Lines tables. This means that each revenue transaction line is associated with a maximum of only one revenue transaction, while a single revenue transaction will contain a maximum of many transaction lines. The Create button should be selected to create the relationship and close the edit relationships screen. 4.4. The completed relationships screen The completed relationships screen shows connections among all of the tables. The ‘‘One-To-Many’’ Relationships are shown with the number ‘‘1’’ and an infinity symbol by the tables (see Fig. 14). The established relationships will allow simultaneous querying of information from multiple tables. The relationships screen can now be closed and saved.
5. Populating the database tables Two available approaches for entering information into the database tables are form input and direct entry into the rows and columns of tables. This database uses direct entry of data into tables in order to avoid the complications of form construction. However, in an actual business, setting up forms for input would be used to facilitate entering information in a more efficient and logical manner. Table information can be entered directly into the database tables under the Tables object. The user simply has to double click the table of interest to bring up the table in datasheet view, which is the format of rows and columns ready for data entry. To facilitate further illustration of the database, the user should populate the
146
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
tables as shown in Fig. 15. The tables should be closed and saved after being fully populated. Due to the referential integrity requirement, it is imperative that data are entered into the tables for Services and Customers before any data for the revenue transactions are entered. For the same reason, the table for Revenue Transaction Lines cannot be completed until the corresponding entry is completed for the transaction in the Revenue Transactions table. The database user will note that the Customer # field in the Revenue Transactions table has a drop-down menu
Fig. 15. Data for populating the tables.
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
147
established during table creation by the Lookup Wizard. The same type feature appears for the Service Type # field in the Revenue Transaction Lines table.
6. The creation of database queries Some database users are unfamiliar with the structured query language (SQL) that is used to pull a subset of information from a database. Fortunately, Microsoft Access provides for a technique known as Query by Example (QBE) that allows users to simply fill a table with desired information and ask the software to build the SQL behind the scenes. This technique will be used in the development of two selection queries. The process of creating a query begins by selecting Queries in the Objects bar and then double-clicking the Create query in Design view option (see Fig. 16). 6.1. Revenue by service provided The accounting firm would like to examine the total amount of revenue that it generates from the different service activities that it offers. The Revenue by Service Provided query will involve the tables for Services and Revenue Transaction Lines. In the top of the query design screen, a table must be shown if any of its fields plays a part in the query process. The Services table is necessary to show the number, name of the service, and hourly rate, while the number of hours worked on the Revenue Transaction Lines table is needed to calculate the revenue generated by each individual service type. When the design view screen initially appears, the creator is shown a box from which he or she may select tables to include in the query. The tables should be added in the order shown above. The show table screen may then be closed. Specific fields to be used in the query may be double clicked to move them into the grid lines below the tables. The first two fields from the Services table should be Service Type # and Service Name. Since total revenue is desired rather than individual transactions, the summation symbol (sigma button) should be selected from the toolbar so that a total row will appear in the grid lines. Fig. 17 shows the complete design for the Revenue by Service Provided query. The third field is a calculated field that may be entered
Fig. 16. Creating queries in design view.
148
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
Fig. 17. Query design for revenue by service provided.
exactly as shown in the third grid box in Fig. 17. This field has been widened to show the full formula. It is also possible to construct this expression using the expression builder shown on the toolbar (magic wand button). Fields such as the one for Total Revenue are known as derivable attributes since they can be calculated from other table fields. Therefore, it is often considered unnecessary to store such fields in the database tables. Once the query is completed, the design screen should be closed and the query saved with the name Revenue by Service Provided. It is also possible to put criteria restrictions on the selection of table rows. For example, Fig. 18 shows the same query as Fig. 17 except that a field has been added to restrict transaction information to a certain time period. Note that the derived field of Total Revenue is also identical but the column width is shortened to allow the
Fig. 18. Adding criteria restrictions to revenue by service provided.
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
149
Fig. 19. Results of query for revenue by service provided.
showing of the added date restriction. In order to add the restriction to the query, the Revenue Transactions table must be added to capture the Transaction Date field. The new table can be added by selecting the ‘‘add table’’ feature to the left of the sigma symbol on the query design toolbar. The check mark in the box for the ‘‘Show’’ line of the grid has been removed for the Transaction Date field since this is only a restriction and unnecessary information otherwise. Fig. 19 shows the results of the query for Revenue by Service Provided. 6.2. Revenue by customer The accounting firm would also like to know the revenue by customer. This query is created in almost the same way as was just illustrated for total revenue by service provided. However, all four database tables will be necessary for this query. The Customers table is needed in order to get the Customer # and Customer Name fields. The Services and Revenue Transaction Lines tables are necessary in order to get the Hourly Rate for each service and Hours worked in calculating the derived field of Total Revenue. In addition, since there is no direct connection between the tables for Customers and Revenue Transaction Lines, the Revenue Transactions table will be needed to complete this query. This is true regardless of whether a Transaction Date restriction is added to the query. Otherwise, the process of establishing this query is similar to the Revenue by Service Provided query. The complete design for the Revenue by Customer query is shown in Fig. 20. A date restriction could be added to the Revenue by Customer query in the same manner as shown in the fourth column of the query grid of Fig. 18. Once the query is completed, the query design screen should be closed and the query saved with the name Revenue by Customer. Fig. 21 shows some results of the query.
150
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
Fig. 20. Query design for revenue by customer.
Fig. 21. Results of query of revenue by customer.
7. The creation of database reports Microsoft Access also contains powerful report creation capabilities. It should be noted that since reports often contain information from more than one entity table, they are usually most efficiently generated from a supporting query of information. Access contains a Report Wizard option that is useful in creating a report from which modifications can be made with relative ease. Fig. 22 contains a sample report of Revenue Earned by Customer for the month of January.
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
151
Fig. 22. January revenue earned by customer report.
The report is based upon a modified version of the Revenue by Customer query that includes additional fields and removes the summation of revenue by customer so that detailed transactions are shown. The modified query was then used as the foundation through which the Report Wizard created the report. The report contains both label fields that serve as headings and descriptions, and text fields that serve as data items that are queried from the database. The report also makes use of a sorting and grouping feature to provide a customer header in the report, so that information can be summarized by individual customer. A section for report detail lines for the customer header provides the specific transaction information for each customer. Sections for customer and report footers provide places for accumulating the customer and report totals, respectively. The different report components for headers, detail lines, and footers are actually spaces in the design view of the report in which the label and text boxes are placed according to the desired format of the report. The user of the database can create many different types of reports by using the report wizard to create an initial report, and then making modifications regarding the placement of the different text and label fields.
8. Summary The article provided a means for students to obtain experience in constructing a relational database for processing revenue transactions. Although the design was kept simple for illustration purposes, other fields and tables could be added to the database as long as entity information is appropriately separated and linked. For example, if the model involved more than one accountant, an entity table for accountants could easily be added to determine revenue generated by employee. In addition, supplemental customer information could be added to the Customers table
152
J.S. Zanzig, B.-Y. Tsay / J. of Acc. Ed. 22 (2004) 131–152
to allow, for example, analysis of revenue by geographic area. The simple model presented in this paper begins by demonstrating the technique of REA modeling to show the student the logical determination of database entities and relationships. This is then followed by constructing a database involving the creation of entity tables, the creation of table relationships, the preparation of queries, and an overview of some fundamental concepts of report processing. The basics presented in this article can help students understand how a relational database can be used to capture and report many different types of information.
References Chen, P. P. (1967). The entity-relationship model – Toward a unified view of data. ACM Transactions on Database Systems, 1(March), 9–36. Dunn, C. L., & McCarthy, W. E. (1997). The REA accounting model: Intellectual heritage and prospects for progress. Journal of Information Systems (Spring), 31–51. McCarthy, W. E. (1979). An entity-relationship view of accounting models. The Accounting Review (October), 667–686. McCarthy, W. E. (1982). The REA accounting model: a generalized framework for accounting systems in a shared data environment. The Accounting Review (July), 554–578. Sorter, G. (1969). An ‘events’ approach to basic accounting theory. The Accounting Review (January), 12– 19.
