Database Design Chapters 17 and 18.

Slides:



Advertisements
Similar presentations
Database Design Using the REA Data Model
Advertisements

Business Processes, Data Modeling and Information Systems
Database Systems: Design, Implementation, and Management Tenth Edition
Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.
ENTITY RELATIONSHIP MODELLING
Copyright © 2015 Pearson Education, Inc. Database Design Chapters 17 and
Accounting System Design
Modeling the Data: Conceptual and Logical Data Modeling
©2003 Prentice Hall Business Publishing, Accounting Information Systems, 9/e, Romney/Steinbart 5-1 Accounting Information Systems 9 th Edition Marshall.
FIS 431/631 Financial Information Systems: Analysis and Design REA Modeling Joe Callaghan Oakland University Department of Accounting & Finance.
Technology Review-II Professor Martin Professor Xiong CSUS
Database Design Using the REA Data Model
1 The Accounting REA Model as an Information Engineering Interaction Model Slides 5.
A Quick Review of Analysis Stages of the Systems Development Life Cycle Planning Analysis Design Construction.
FIS 431/631 Financial Information Systems: Analysis and Design ERD & Normalization Joe Callaghan Oakland University Department of Accounting & Finance.
Implementing an REA Model in a Relational Database
Database Design Using the REA Data Model
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
Database Design Using the REA Data Model
1. 2 Data Modeling 3 Process of creating a logical representation of the structure of the database The most important task in database development E-R.
Database Design Using the REA Data Model
Chapter 17 Database Design Using the REA Data Model Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 17-1.
Chapter 17 Database Design Using the REA Data Model Copyright © 2012 Pearson Education 17-1.
Business Process Modeling
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
REA analysis and E-R diagramming December 2, 2008.
1 ER Modeling BUAD/American University Entity Relationship (ER) Modeling.
The REA Model. The REA model provides structure for developing an accounting database It helps to identify It helps to The REA Model.
Accounting Information Systems 9th Edition
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
© 2006 Prentice Hall Business Publishing Accounting Information Systems, 10/e Romney/Steinbart1 of 96 C HAPTER 17 Special Topics in REA Modeling for the.
Acct 316 Acct 316 Acct 316 Data Modeling and Database Design 5 UAA – ACCT 316 Accounting Information Systems Dr. Fred Barbee Chapter.
Implementing an REA Model in a Relational Database
1 Relational Databases and SQL. Learning Objectives Understand techniques to model complex accounting phenomena in an E-R diagram Develop E-R diagrams.
Implementing an REA Model in a Relational Database
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
3 & 4 1 Chapters 3 and 4 Drawing ERDs October 16, 2006 Week 3.
© 2006 Prentice Hall Business Publishing Accounting Information Systems, 10/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
© 2006 Prentice Hall Business Publishing Accounting Information Systems, 10/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
Entity Relationship Diagram (ERD). Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 6 Modeling the Data: Conceptual and Logical Data Modeling.
Data Modeling and Entity-Relationship Model I
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 138 C HAPTER 15 Database Design Using the REA Data Model.
Database Design Chapters 17 and 18.
Implementing an REA Model in a Relational Database
Tutorial 3 Data Modelling.
TMC2034 Database Concept and Design
© The McGraw-Hill Companies, All Rights Reserved APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES.
Implementing an REA Model in a Relational Database
Tables and Their Characteristics
Database Design Using the REA Data Model
Lecture on Data Modeling and Analysis
Implementing an REA Model in a Relational Database
Accounting Information Systems 9th Edition
Database Design Using the REA Data Model
Accounting System Design
ERD’s REVIEW DBS201.
Database Fundamentals
Database Systems: Design, Implementation, and Management Tenth Edition
MIS2502: Data Analytics Relational Data Modeling
Accounting System Design
Database Design Using the REA Data Model
Chapter 3: Modeling Data in the Organization
CHAPTER 2 - Database Requirements and ER Modeling
Entity-Relationship (E-R) Modeling
Presentation transcript:

Database Design Chapters 17 and 18

Learning Objectives Learn the steps to design and implement a database system. Learn how is an entity-relationship (E-R) diagram is drawn. Learn how E-R diagrams are read and what they reveal about the business activities and policies of the organization being modeled

Database Design Process Initial Planning – Need Feasibility (Technological and Economical) User Needs/Scope (# Users/#Transactions) Preliminary Hardware and Software Develop Schemas Conceptual, Internal, and External Translate internal schema into database structure Develop New Applications Transfer data from existing system to new AIS Test New System Train Employees Monitor System Performance Monitor User Satisfaction Identify Needs for System Enhancements and Modifications

Data Modeling Process of defining a database so that it faithfully represents all aspects of the organization, including its interactions with the external environment. Entity-relationship (E-R) diagrams REA data model

REA Modeling Resources Events Agents Things that have economic value to the organization (e.g., inventory, cash) Events Various business activities that management wants to collect information on Agents People and organizations that participate in events (both internal (e.g., employees) and external (e.g., customers/vendors) to the organization) REA stands for Resource, Events, Agents. If you recall from Chapter 1, Figure 1-2 (on p. 7) actually depicts the various transaction cycles in the form of the “give-get” relationship of events for each subsystem of an AIS.

Review of Database Terms entity, relation, table attribute, field, column tuple, record, row instance of an entity primary key foreign key relationship cardinality, modality

ENTITY-RELATIONSHIP DIAGRAMS In an E-R diagram, entities are depicted as rectangles. But there are no industry standards for other aspects of these diagrams. Course Student

ENTITY-RELATIONSHIP DIAGRAMS Sometimes attributes are listed in the same symbol as the entity itself. Course Course CRN (pk) Course Days Course Time Student Student ID No. (pk) Student Name Student Address This is the approach we will be using in this class. However many of the examples in these slides do not show attributes since the focus is on relationship issues. A final ERD should show all attributes of each entity.

RELATIONSHIPS A relationship is a natural business association that exists between one or more entities. Entities are connected by a line Should use active verbs to describe the relationship One verb can describe the relationship in both directions Customer Order Places

CARDINALITY Cardinality describes the maximum number of instances of one entity that may be related to a specific instance of another entity. For example, the cardinalities between Order and Customer answer the questions: How many customers can be associated with a single order that a company receives? How many orders can be associated with a single customer of the company?

MODALITY Modality describes the minimum number of instances of one entity that can be related to a specific instance of another entity. For example, the cardinality between Order and Customer answers the questions: Does each order have to be associated with a customer? Does each customer have to be associated with an order?

CARDINALITY and MODALITY Using the crow’s feet notation: The symbol for zero is a circle: O The symbol for one is a single stroke: | The symbol for many is the crow’s foot:

CARDINALITY and MODALITY Order Customer is placed by Because all relationships are bidirectional, modality and cardinality must be defined in both directions for every relationship.

CARDINALITY and MODALITY Order Customer is placed by The modality symbol next to customer is the symbol for one. This symbol means that for every occurrence of an order, there must be a minimum of one customer involved.

CARDINALITY and MODALITY Order Customer is placed by The cardinality symbol next to customer is the symbol for one. This symbol means that for every occurrence of an order, there can be no more than one customer involved.

CARDINALITY and MODALITY Order Customer is placed by The modality symbol next to order is the symbol for zero. This symbol means that for every customer in the database, there must be a minimum of zero orders. This minimum of zero allows the company to add a customer to its database before any orders have been placed by that customer, i.e., a prospective customer can be included.

CARDINALITY and MODALITY Order Customer is placed by The cardinality symbol next to order is the symbol for many. This symbol means that for every customer in the database, there can be many orders involved. Obviously, a company can allow multiple orders from an individual customer.

CARDINALITY and MODALITY Places Customer Order Claims Employee Dependent Teaches Instructor Section Claims Employee Dependent

CARDINALITY and MODALITY It is not a “one size fits all” world for relationships and cardinalities. The cardinalities between two entities can vary based on how the particular company does business. It reflects facts about the organization that are obtained during the requirements definition stage of the database design process.

CARDINALITY and MODALITY Customers pay for each sale with a maximum of one payment (typical for retail stores). Each cash receipt from a customer relates to one (and only one) sale. Sale Cash Receipt Simple Convenience Store Sale.

CARDINALITY and MODALITY Customers pay for each sale with a maximum of many payments (installments). Each cash receipt from a customer relates to one (and only one) sale. Sale Cash Receipt Installment Sales (One item, many payments).

CARDINALITY and MODALITY Customers make only one payment for a sale. Each cash receipt from a customer can relate to multiple sales (e.g., they pay for all sales that month in one payment). Sale Cash Receipt Customer pays once a month for all transactions that occurred that month.

CARDINALITY and MODALITY Customers may make multiple payments for a particular sale. A cash receipt from a customer may relate to more than one sale. Sale Cash Receipt

CARDINALITY and MODALITY Three Types of Relationships Three types of relationships are possible between entities. Relationships depend on the cardinality on each side of a relationship. A one-to-one relationship (1:1) exists when the maximum cardinality for each entity in the relationship is 1. A one-to-many (1:N) relationship exists when the maximum cardinality on one side is 1 and the maximum on the other side is many. A many-to-many (M:N) relationship exists when the maximum on both sides is many.

CARDINALITY and MODALITY College Both cardinalities are one, so this is a one-to-one relationship. Dean

CARDINALITY and MODALITY Order Customer The maximum number of customers that can be involved in each order is one. The maximum number of orders that can be associated with any individual customer is many. This is a one-to-many (1:N) relationship.

CARDINALITY and MODALITY Inventory Sale The maximum number of inventory items that can be sold in one sale is many. The maximum number of sales that can occur for a particular inventory item is many. This is a many-to-many (M:N) relationship.

Implement One-to-One Relationships In a relational database, one-to-one relationships between entities can be implemented by merging the two tables/entities together.

Implement One-to-Many Relationships One-to-many relationships between entities can be implemented by placing the primary key of the entity that can occur only once as a foreign key in the entity that can occur many times. EXAMPLE: The primary key for salesperson (which can occur only once per sale) is a foreign key in the sale table/entity (which can occur many times for a particular salesperson). If you tried to do the opposite, you would not have single-valued entries in the tables

Implement One-to-Many Relationships !

Implement Many-to-Many Relationships In a relational database, many-to-many relationships between entities can be implemented by creating a new entity that links the other two entities together. In most cases, the primary key of the new entity consists of the concatenated primary key attributes of the entities that it is relating together. The table/entity names for M:N relationships should be hyphenated concatenations of the entities involved in the relationship.

Implement Many-to-Many Relationships Student Student ID (pk) Student first name Student last name … Section Section CRN (pk) Section day Section time … registers for Student Student ID (pk) Student first name Student last name … Student-Section Student ID (pk)(fk) Section CRN (pk)(fk) Section Section CRN (pk) Section day Section time … participates in Is for a

SUMMARY: DESIGNING AN E-R Diagram Create an entity for each distinct thing (people, places, events, etc.) that the organization wants to track. Identify a primary key for each entity Assign non-key attributes to appropriate entities Using knowledge of business processes identify relationships between entities and assign modality and cardinality to each relationship. Merge one-to-one relationships together and use foreign keys to implement one-to-many relationships. Draw new entities to handle with many-to-many relationships and add appropriate attributes, cardinalities, modalities, etc. Create tables (one for each entity on the ERD) for sample data and check for rule violations or anomalies