AIS LECTURE 2: Database Management Systems

Introduction to Databases
The enterprise database is at the heart of Accounting Information Systems The chapter discusses the major types of databases that are available and how organizations undertake database design for accounting information systems. Larger organizations store information in data warehouses in ways that let managers analyze it to gain important insights. Many companies combine their data resources with decision support systems, executive information systems, group decision systems, and other advanced technology-based systems to improve decision making and operations.
2 2

Two Approaches To Business Event Processing

Applications Approach Concentrates on the process being performed Data support the role of the programs that run in each application system Each application collects and manages its own data in separate, distinguishable files Data redundancy can cause inconsistencies among the same data in different files. This increases storage costs because the system must store and maintain multiple versions of the same data in different files. Data residing in separate files are not shareable among applications. Redundant data stored in multiple files can become inconsistent when information is updated in one file and not in other files
3

Two Approaches To Business Event Processing

Database Approach Facts about events are stored in relational database tables instead of separate files This solves many of the problems caused by data redundancy. The use of databases has improved the efficiency of processing business event data by eliminating data redundancies and improving data integrity. Makes it possible for the creation of integrated business information systems that include data about all of a companys operations in one massive collection of relational tables Multiple users from throughout the organization can view and aggregate event data in a manner most conducive to their needs.

Two Approaches To Event Processing

Problems with Applications Approach

Data redundancyfiles stored may include redundant information increasing storage requirements and risk of inconsistency Data in files is not shareable across applications because applications depend on a fixed record layout in data files

Record Layout Applications Approach

Each application stores all the data required for analysis Shows many redundancies across applications/files Data lacks integrity when the data stored by one application is inconsistent with data stored by another application

Database Management Systems

DBM is a set of integrated programs designed to simplify the tasks of creating, accessing, and managing data. DBM systems integrate a collection of files that are independent of application programs and are available to satisfy a number of different processing needs. The database contains data related to all the organizations applications in one place The DBM system supports normal data processing needs and enhances the organizations management activities by providing data useful to managers. The data is independent of the application that created the data (i.e., can be changed/used by other applications) We will use the term enterprise database synonymously with database management system or DBMS.
8

Relational Database Tables

The next slide shows a database with data stored in a relational structure This is most common type of database structure used in businesses today. The data from three files are now stored in four tables:
CUSTOMERS (instead of the customer master data file) INVENTORY_ITEMS (instead of the inventory master data file) SALES_ORDERS SALES_LINES (the two tables replace the sales order master data file)

The logical database view is how the data appear to the user to be stored.
This view represents the structure that the user must use to extract data from the database.
9

Disadvantages of DBMS
1. Expensive to implement 2. If the DBMS fails, all of the organizations information processing halts. 3. Database recovery and contingency planning are more important than in the applications approach 4. When more than one user attempts to access data at the same time, the database can face contention or concurrency problems.
Record locking can help mitigate such problems but are beyond the scope of this course

5. Territorial disputes over who owns the data, such as who is responsible for data maintenance (additions/deletions/changes) to customer data.
Sales department might think it should own those data Credit department or AR might argue with that contention.

To cope with these and other problems, most companies that have adopted the database approach have found it necessary to create a database administrator function

10

Elements/Parts of a Relational Database

Tablesplace to store data Queriesretrieve data Formson-screen presentations of data collected by queries Reportsprinted lists and data summaries collected by queries

11

Comparison of Database and Spreadsheet

Database
Cell can contain only one Cell can contain text, numbers, data type formula or graphic Each row in the database Rows need not be unique must be unique and include a unique identifier Columns often store dissimilar attributes (primary key or composite key) Columns store one attribute

Spreadsheet

12

Classifying and Coding Data

Types of coding
1. 2. 3. 4. 5.

Sequential Block Significant digit Hierarchical Mnemonic

13

Functional Dependence and Primary Keys

An attribute (a column in a table) is functionally dependent on a second attribute (or a collection of other attributes), if a value for the first attribute determines a single value for the second attribute at any time.
If functional dependence exists, one would say that the first attribute determines the second attribute.

A primary key contains a value that uniquely identifies a specific row in a table
A candidate attribute (a column or collection of columns) in a table is that tables primary key if: 1. All attributes in the table are functionally dependent on the candidate attribute. 2. No collection of other columns in the table, taken together, has the first property.
14

Entity-Relationship Models (REA)

Popular data modeling approach Entities and relationships are determined through systems analysis Common accounting entities include:
Resourcesthing the company owns Eventsoccurrences related to resources Agentspeople or organizations that participate in events

15

Entity-relationship diagram

16

REA
Identify Entities
Categories of entities
Resources Events Agents Locations

Identify relationships that connect the entities

shown in the E-R diagram as connecting lines with diamonds that describe the nature of the relationship.

Create tables and relationships

the analyst continues the data modeling process transforming the data model into a logical design for the database.
17

Characteristics of Relationships
Relationships between entities are determined by analyzing the system The cardinality is the degree to which each entity participates in the relationship, e.g., 1:N, pronounced one-to-many.

18

Create the E-R Diagram in 5 Steps

Create a logical model of the database
Create tables for each entity Determine primary keys Determine attributes Implement relationships through primary keys and relationships 5. Define relationship tables
1. 2. 3. 4.

Implement the database using an available DBMS

19

Key Attributes
A unique attribute/value is needed to locate the desired record in the database
An attribute with a unique value is known as a key attribute In implementing the database, the key attribute becomes the primary key Figure 6.2 follows next

20

Symbols used in E-R and REA Diagrams

21

Relationships
Relationships are associations between entities. Entities must be logically linked to show the relationships between them These relationships map and define how data can be extracted from the database This mapping is the development of the E-R diagram A three-step strategy is generally most effective in identifying all the relationships that should be included in a model.
1. 2. 3.

Identify users existing and desired information requirements to determine whether relationships in the data model can fulfill those requirements. Evaluate each of the entities in pairs to determine whether one entity in the pair provides a better description of an attribute contained in the other entity in the pair. Evaluate each entity to determine if there would be any need for two occurrences of the same entity type to be linked.

22

REA Approach
The Figure 6.3 shows three entities and their attributes. Using REA, we have identified one event and two agents for business process of billing for professional services.
The WORK_COMPLETED entity is an event. The CLIENT and EMPLOYEE entities are agents.

CLIENT is an entity but not an attribute of WORK_COMPLETED

However, CLIENT does improve the description of an attribute for the work completedthe client for whom the work was performed. This descriptive value suggests that a relationship exists between the CLIENT entity and the entity capturing the completed work as shown We often can identify the need for defining relationships (such as Works_For) by examining the prescribed entities as pairs (in this case, we examined the pair CLIENT and WORK_COMPLETED) to identify logical linkages that would improve the description of an entitys attributes.
23

Relationship Types in the REA Model of the Client Billing Business Process

24

Recursive relationship
A recursive relationship is a relationship between two different instances of an entity. When one employee supervises other employees, this relationship should be shown in our database The previous slide shows how a recursive relationship is displayed in an REA data model diagram. We could show employees and supervisors as separate entities in the model. Unfortunately, this separate entity approach yields data redundancies when the supervisor is supervised by a third employee. Thus, it is easier and more logically correct to use a recursive relationship to the entity, EMPLOYEE. In this recursive relationship, a link is created between the employee and his/her supervisor. As shown in part (b) of Figure 6.3 the diamond represents the recursive relationship, Supervises, just as it would be used to show any relationship such as the Works_For relationship in part (a)
25

Constraints in the E-R Diagram

Cardinality is the most common constraint specified in E-R diagrams. The other meaningful constraint that may be specified is participation.
The participation constraint specifies the degree of minimum participation of one entity in the relationship with the other entity.

26

Constraints in the E-R Diagram

Although the participation constraint does provide more information, it is still used less frequently than the cardinality constraint. In this book, we will present the diagrams using the maximum cardinality and will omit the participation (or minimum) constraints. You should know that both types of constraints and notation are used because, as a member of the development team, as an auditor, or as a user, you will need to communicate using the methods selected by the organization with which you are working.
27

Constraints in the E-R Diagram

In Figure 6.4 part (b), the participation constraints appear in the diagram.
In the Works relationship, not all employees are billable Some employees are new and are not yet billable Others might be involved with training or new business development.

The many cardinality in part (a) of the diagram only specifies the maximum participation in the relationship, not the minimum.
The minimum participation in the relationship can be zero or one. The notation (0,N) on the line on the right in part (b) reflects the range of zero to many occurrences of work being completed on client projects, where the numbers reflect (minimum, maximum). The notation (1,1) on the line on the left side in part (b), illustrates that for any given occurrence of work completed for a client, the maximum of one employee providing the specific service still holds. The (1,1) relationship reflects that there is a required participation of one, and only one, employee.
28

Relationship Constraints in the Client Billing Business Process

29

Relational Database Concepts

A relation is a collection of data representing multiple occurrences of a resource, event, or agent.
These relations correspond to the entities in the E-R model and the REA model.

A tuple is a set of data that describes a single instance of the entity represented by a relation
For example, one employee is an instance of the EMPLOYEE relation.

Attributes, as in an E-R model, represent an item of data that characterizes an object, event, or agent.
Attributes are often called fields.
30

Example of a Relation

31

Developing an REA Model

The objective in the development of an REA model is to integrate the data in a way that allows managers and other users access to the information they need to perform effectively. Figure 6.5 presents the integrated REA data model for the billing and human resources business processes.

32

An Integrated REA Model for the Client Billing and Human Resources Processes

33

Steps in Mapping an REA Model to a Relational DBMS

1. 2. 3. 4.

5.

Create separate relational table for each entity. Determine primary key for each relation. The primary key must uniquely identify any row within table. Determine the attributes for each of the entities Implement the relationships among the entities by ensuring that the primary key in one table also exists as an attribute in every table for which there is a relationship specified in the REA diagram. Determine attributes, if any, for relationship tables

34

Steps 1 and 2: Mapping an REA Model to a Relational DBMS

Create separate relational table for each entity. First specify the database schema before expanding the relations to account for specific tuples. Notice that each of the entities in Figure 6.5 has become a relation in Figure 6.8 To complete the schema, however, steps 2 and 3 also must be completed. 2. Determine primary key for each relation. The primary key must uniquely identify any row within table.
1.

35

Step 3: Mapping an REA Model to a Relational DBMS

3.

Determine attributes for each of the entities In Figure 6.5, a complete REA model includes all the attributes, including the key attribute The key attribute specified in the REA model is matched to the corresponding attribute in the relation
An example is Employee_Number in the EMPLOYEE agent entity shown in Figure 6.5

To create a composite primary key, you simply break the key down into its component subattributes.
For instance, in the implementation of the WORK_COMPLETED event relation, Employee_No, Date, and Client_No are three distinct attributes in the relation, but also combine to form the composite primary key.

Note the direct mapping between the entities and attributes in the REA model and the relations and attributes, respectively, in the relational schema
The completed schema is presented in Figure 6.8

36

Schema for the Client Billing and Human Resources Portion of the Database

37

Step 4: Mapping an REA Model to a Relational DBMS

4.

Implement the relationships among the entities by ensuring that the primary key in one table also exists as an attribute in every table for which there is a relationship specified in the REA diagram. With the availability of the full REA model, the mapping of the relationships in the model to the relationships in the relational schema is straightforward. References to the key attributes of one entity are captured by including a corresponding attribute in the other entity that participates in the relationship. All of the relationships in Figure 6.5 are 1:N relationships, which simplifies the process.
The REA model for the client billing and human resource process
38

Step 4 continued
One-to-many (1:N or N:1) relationships are implemented by including the primary key of the table on the one side of the relationship as an attribute in the table on the many side of the relationship
This is the situation we have for all the relationships in Figure 6.5: The Integrated REA Model for the Client Billing and Human Resources Process

The linking between these relationships in the schema are drawn in Figure 6.9
The recursive relationship with EMPLOYEE uses Supervisor_No identifies the correct EMPLOYEE as the supervisor

One-to-one (1:1) relationships are even easier

Follow the same steps used for 1:N relationships, but you can start with either table.

39

Referential Constraints for the Relational Schema

40

Step 4 continued
Many-to-many (M:N) relationships are implemented by creating a new relation whose primary key is a composite of the primary keys of the relations to be linked.
We dont have any M:N relationships in the current REA Model We would need a relationship between the EMPLOYEE and CLIENT entities, which would then be an M:N relationship. This creates problems because these tables (that have been normalized) cannot store multiple client numbers in a single EMPLOYEE tuple. Similarly, a single CLIENT tuple cannot store multiple employee numbers. In that situation, we would need to develop a M:N relation to link the EMPLOYEE and CLIENT relations as shown Figure 6.10

41

Linking Two Relations in a Many-to-Many Relationship

42

Step 5: Mapping an REA Model to a Relational DBMS

5. Determine attributes, if any, for relationship tables.
Again, in the extended version of the REA model, the attributes map directly to the relations.

The implementation of the schema is shown in Figure 6.11

43

Implemented Relational Schema

44

Decision Support Systems: DSS

Information systems that assist managers with unstructured decisions by retrieving data and generating information Possesses interactive capabilities Can answer ad-hoc inquires Provide data modeling facilities such as spreadsheets Supports non-recurring, relatively unstructured decision making

45

Executive information system: ESS

Information systems often considered a subset of DSS, that combine information from the organization and the environment Organize and analyze the information In a form suitable for managers to make decisions

46

Group Support Systems: GSS

Computer based systems that support collaborative intellectual work such as
Idea generation Elaboration Analysis Synthesis Decision making

GSS use technology to solve the time and place dimension problems associated with group work Also known as GDSS or Group Decision Support Systems

47

Expert Systems: ES
An information system that emulates the problem solving techniques of human experts

48