Chapter 4

Relational Database, Data Modeling and Data Base Design

 Data Hierarchy

• Field
• Attributes about
an entity
• Record
• Related group of
fields
• File
• Related group of
records
• Database
• Related group of
files
Advantages of Database Systems

• Data Integration
• Files are logically combined and made accessible to various systems.
• Data Sharing
• With data in one place it is more easily accessed by authorized users.
• Minimizing Data Redundancy and Data Inconsistency
• Eliminates the same data being stored in multiple files, thus reducing inconsistency in
multiple versions of the same data.
• Data Independence
• Data is separate from the programs that access it. Changes can be made to the data without
necessitating a change in the programs and vice versa.
• Cross-Functional Analysis
• Relationships between data from various organizational departments can be more easily
combined.
Database Terminology

• Database Management System (DBMS)

• Interface between software applications and the data in files.
• Database Administrator (DBA)
• Person responsible for maintaining the database
• Data Dictionary
• Information about the structure of the database
• Field names, descriptions, uses
Logical vs. Physical

• Physical View
• Depends on explicitly knowing:
• How is the data actually arranged in a file
• Where is the data stored on the computer
• Logical View
• A Schema separates storage of data from use of the data
• Unnecessary to explicitly know how and where data is stored.
 Schemas
• Describe the logical structure of a
database
• Conceptual Level
• Organization wide view of the data
• External Level
• Individual users view of the data
• Each view is a subschema
• Internal Level
• Describes how data are stored and
accessed
• Description of: records, definitions,
addresses, and indexes
DBMS Languages

• Data Definition Language (DDL)

• Builds the data dictionary
• Creates the database
• Describes the subschema
• Specifies record or field security constraints
• Data Manipulation Language (DML)
• Changes the content in the database
• Updates, insertions, and deletions
• Data Query Language (DQL)
• Enables the retrieval, sorting, and display of data from the database
Relational Database

• Relational data model represents the conceptual and external level

schemas as if data are stored in tables.
• Table
• Each row, a tuple, contains data about one instance of an entity.
• This is equivalent to a record
• Each column contains data about one attribute of an entity.
• This is equivalent to a field
 A Relational Table
Row (Record)

Each row contains multiple attributes Same type of data

describing an instance of the entity. In
Column (Field)
this case, inventory.
Attributes

• Primary Key
• An attribute or combination of attributes that can be used to uniquely
identify a specific row (record) in a table.
• Foreign Key
• An attribute in one table that is a primary key in another table.
• Used to link the two tables
Database Design Errors

• If database is not designed properly data errors can occur.

• Update Anomaly
• Changes to existing data are not correctly recorded.
• Due to multiple records with the same data attributes
• Insert Anomaly
• Unable to add a record to the database.
• Delete Anomaly
• Removing a record also removes unintended data from the database.
Design Requirements for Relational Database

1. Every column must be single valued.

2. Primary keys must contain data (not null).
3. Foreign keys must contain the same data as the primary key in
another table.
4. All other attributes must identify a characteristic of the table
identified by the primary key.
Normalizing Relational Databases

• Initially, one table is used for all the data in a database.

• Following rules, the table is decomposed into multiple tables related
by:
• Primary key–foreign key integration
• Decomposed set of tables are in third normal form (3NF).
Microsoft Access Query #1
Microsoft Access Query #2
Microsoft Access Query #3
Microsoft Access Query #4
Microsoft Access Query #5
Database Design Using the REA Data Model
Database Design Process

Conceptual
System Analysis Physical Design
Design

Implementation Operation &

& Conversion Maintenance
The System Analysis Process

• Systems Analysis
• Initial planning to determine the need for and feasibility of developing a new system
• Judgments about the proposal’s technological and economic feasibility
• Identify user information needs
• Define the scope of the proposed new system
• Gather information about the expected number of users and transaction volumes to make
preliminary decisions about hardware and software requirements
• Conceptual Design
• Developing the different schemas for the new system at the conceptual, external, and internal
levels
The System Analysis Process (cont’d)

• Physical Design
• Translating the internal-level schema into the actual database structures that will be implemented
in the new system
• New applications are developed
• Implementation and Conversion
• Includes all the activities associated with transferring data from existing systems to the new
database AIS
• Testing the new system
• Training employees
• Maintaining the New System
Data Modeling

• Process of defining an information system so it represents an

organizations requirements
• Occurs at two stages of the design process:
• System analysis
• Conceptual design
• Data models:
• Data flow diagrams (Chapter 3)
• Flow charts (Chapter 3)
• Entity-relationship diagrams (Chapter 17)
Entity-Relationship Diagrams

• Used to graphically represent a database schema

• Depicts entities
• Anything an organization wants to collect information about
• Relationships between entities
E-R Diagram Variations
Resources-Events-Agents Diagram

• Developed for designing AIS

• Categorizing entities into:
• Resources
• Things that have economic value
• Events
• Business activities
• Management wants to manage and control
• Agents
• People and organizations that participate in events
REA Diagram Rules

1. Each event is linked to at least one resource that it affects.

2. Each event is linked to at least one other event.
• Types of links (relationships):
• Get events
• Give events
• Participation events
3. Each event is linked to at least two participating agents.
Business Cycle Give–Get Relationships
Revenue Cycle REA Diagram
Developing an REA Diagram

1. Identify the events about which management wants to collect

information.
2. Identify the resources affected by each event and the agents who
participate in those events.
• What economic resource is reduced by the “Give” event?
• What economic resource is acquired by the “Get” event?
• What economic resource is affected by a commitment event?
3. Determine the cardinalities of each relationship.
Cardinalities
• Describe the nature of relationships between entities
• How many instances of one entity can be linked to each specific instance of another entity
• Minimum can be: 0 or 1
• Maximum can be: 1 or Many
Three Types of Relationships
• Relationship type is based on maximum cardinality:
• One-to-One:

• One-to-Many:

• Many-to-Many:
Implementing an REA Model in a Relational Database
REA Diagram—Revenue Cycle
REA Diagram—Expenditure Cycle
REA Diagram—Payroll Cycle
REA Redundancies

• Separate REA for an organization will have redundant entities

• Resource
• Each resource entity must be connected to:
• The resource entity is linked to event entities in one business cycle and to event
entities in the other cycle
• One event that increases the resource and,
• One event that decreases the resource
• No effect on cardinality
• Events
• Alters the minimum cardinalities associated with the other events that are related to the
merged event
• May be linked to either an event that is part of one business cycle or to an event
that is part of another cycle but cannot be linked to both events
• The minimum cardinality associated with the other events must be 0 in the
integrated REA diagram
Payroll Cycle Expenditure Cycle

Integrated REA Diagram

Revenue Cycle
Cardinality Effect of Merging Resources

Cardinalities between resource and entities remain the same.

Cardinality Effect of Merging Events

The cardinality between Disburse Cash and Supplier and Employee (as payee) is now 0
to 1, that is, a disbursement can be made to the supplier or the employee but not both!
Rules for Creating Integrated REA Diagram

1. Every event must be linked to at least one resource.

2. Every event must be linked to two agents who participate in that
event.
3. Every event that involves the disposition of a resource must be
linked to an event that involves the acquisition of a resource.
4. Every resource must be linked to at least one event that
increments that resource and to at least one event that
decrements that resource.
5. If event A can be linked to more than one other event, but cannot
be linked simultaneously to all of those other events, then the REA
diagram should show that event A is linked to a minimum of 0 of
each of those other events.
Using REA Diagram to Create Relational
Database
• Advantage:
• Ensures the elimination of anomalies:
• Update
• Insert
• Delete
 REA to Database Steps
1. Create a table for each distinct entity in the diagram and for each
many-to-many relationship.
2. Assign attributes to appropriate tables.
• Identify primary keys:
• Attributes that uniquely identifies each record.
• For M:N relationships the primary key consists of two attributes that represent the primary
keys of each entity linked in that relationship.
• Identify remaining attributes for table.
3. Use foreign keys to implement one-to-one and one-to-many
relationships.
• An attribute of one entity that is itself the primary key of another entity.
Retrieving Information from REA Database

• Journals
• Information contained in event tables
• Ledgers
• Information contained in resource tables
• Financial statements
• Information contained in resources and
• Information on imbalances
• Accounts receivable
• Sales transactions for which customer payments have not yet been
received
• Accounts payable
• Purchases from suppliers that have not yet been paid for
End of Chapter
?