By Hollander, Denna, Cherrington Accounting, Information Technology, and Business Solutions, 2nd Edition Irwin/McGraw-Hill  The McGraw-Hill Companies,

Slides:



Advertisements
Similar presentations
System Development Life Cycle (SDLC)
Advertisements

Entity-Relationship (ER) Modeling
BUSINESS DRIVEN TECHNOLOGY Plug-In T4 Designing Database Applications.
Alternative Approach to Systems Analysis Structured analysis
The Acquisition / Payment Process
Describing Process Specifications and Structured Decisions Systems Analysis and Design, 7e Kendall & Kendall 9 © 2008 Pearson Prentice Hall.
Karolina Muszyńska Based on:
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
Copyright Irwin/McGraw-Hill Data Modeling Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.
MIS 325 PSCJ. 2  Business processes can be quite complex  Process model: any abstract representation of a process  Process-modeling tools provide a.
Copyright © 2015 Pearson Education, Inc. Database Design Chapters 17 and
©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.
PROCESS MODELING Transform Description. A model is a representation of reality. Just as a picture is worth a thousand words, most models are pictorial.
Pertemuan 12 Systems Analysis and Design of a Business Event Driven System Matakuliah: M0034 /Informasi dan Proses Bisnis Tahun: 2005 Versi: 01/05.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart1 of 85 C HAPTER 1 Accounting Information Systems: An Overview.
Irwin/McGraw-Hill Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition.
Principles of Information Systems, Seventh Edition2 An organization’s TPS must support the routine, day-to- day activities that occur in the normal course.
1 The Accounting REA Model as an Information Engineering Interaction Model Slides 5.
Pertemuan 17 The Sales/Collection Business Process Matakuliah: M0034 /Informasi dan Proses Bisnis Tahun: 2005 Versi: 01/05.
Lesson-19 Data Modeling and Analysis
A Quick Review of Analysis Stages of the Systems Development Life Cycle Planning Analysis Design Construction.
Data Modeling and the Entity-Relationship Model Chapter Four DAVID M. KROENKE and DAVID J. AUER DATABASE CONCEPTS, 5 th Edition.
Pertemuan 11 Systems Analysis and Design of a Business Event Driven System Matakuliah: M0034 /Informasi dan Proses Bisnis Tahun: 2005 Versi: 01/05.
Process Modelling Using Data Flow Diagrams - Building and Levelling Them; Process Modelling Using Function Decomposition CSE Information Systems.
APPENDIX C DESIGNING DATABASES
Database Design Using the REA Data Model
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring.
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Accounting Information Systems: An Overview
Chapter 6: The Traditional Approach to Requirements
System Analysis Overview Document functional requirements by creating models Two concepts help identify functional requirements in the traditional approach.
Systems Analysis and Design: The Big Picture
Copyright 2004 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Second Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Computer System Analysis Chapter 10 Structuring System Requirements: Conceptual Data Modeling Dr. Sana’a Wafa Al-Sayegh 1 st quadmaster University of Palestine.
PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 3rd Edition Copyright 2006 © John Wiley & Sons, Inc. All rights reserved..
Irwin/McGraw-Hill Copyright © 2000 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS5th Edition.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Database Design Using the REA Data Model
The Acquisition/Payment Process
Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition Irwin/McGraw-Hill.
Chapter 14 Information System Development
Pertemuan 08 Systems Analysis and Design of a Business Event Driven System Matakuliah: M0034 /Informasi dan Proses Bisnis Tahun: 2005 Versi: 01/05.
Describing Process Specifications and Structured Decisions Systems Analysis and Design, 7e Kendall & Kendall 9 © 2008 Pearson Prentice Hall.
THE SALES/COLLECTION BUSINESS PROCESS
Systems Analysis and Design of a Business Event-Driven System
1 Relational Databases and SQL. Learning Objectives Understand techniques to model complex accounting phenomena in an E-R diagram Develop E-R diagrams.
Copyright © 2004 The McGraw-Hill Companies. All Rights reserved Whitten Bentley DittmanSYSTEMS ANALYSIS AND DESIGN METHODS6th Edition Irwin/McGraw-Hill.
Lecture 4 Conceptual Data Modeling. Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship,
6 Systems Analysis and Design in a Changing World, Fourth Edition.
Detailed Data Modeling. Outline Data Modeling Modeling Constructs –Entities –Relationships –Cardinality Model Basic Rules Advanced Rules Prototyping Process.
1 Information System Analysis Topic-3. 2 Entity Relationship Diagram \ Definition An entity-relationship (ER) diagram is a specialized graphic that illustrates.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring.
Chapter 7 Part II Structuring System Process Requirements MIS 215 System Analysis and Design.
Copyright © 2011 Pearson Education Process Specifications and Structured Decisions Systems Analysis and Design, 8e Kendall & Kendall Global Edition 9.
ACTG 313 September 14, Self-Assessment 5.
Chapter 6 The Traditional Approach to Requirements.
Fundamentals of Information Systems, Sixth Edition
Introduction to Transaction Processing
Developing Information Systems
Lecture on Data Modeling and Analysis
Accounting Information Systems 9th Edition
Database Design Using the REA Data Model
Overview of Business Processes
Systems Analysis & Design
Database Design Chapters 17 and 18.
Chapter 11 Describing Process Specifications and Structured Decisions
Accounting Information Systems and Business Processes - Part I
Presentation transcript:

By Hollander, Denna, Cherrington Accounting, Information Technology, and Business Solutions, 2nd Edition Irwin/McGraw-Hill  The McGraw-Hill Companies, Inc., 2000 Systems Analysis and Design of a Business Event Driven System Chapter 4

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Objective n The objective of this chapter is to help you understand the key steps in analyzing and designing information technology (IT) applications.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Analysis and Design of a Business Event- driven IT Application n Designing quality IT applications requires a thorough understanding of the organization including its current and desired objectives, strategies, value chains, risks, and business processes n There are a variety of methods for analyzing and designing information systems. n How do professionals move from a business need for information to creating the physical IT infrastructure that can provide that information?

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Systems Analysis and Design Methods n Exhibit 1 presents a systems analysis and design life cycle (SDLC) by J.A. Hoffer, J.F. George, and J.S. Valacich n Exhibit 2 displays the systems development process presented by J.L. Whitten, L.D. Bentley, and V.M. Barlow n Other analysis and design approaches, including ä object-oriented analysis and design, ä prototyping, ä systems engineering, ä joint application design, ä participatory design, ä essential system design, ä automating the SDLC using CASE tools

Implementation Maintenance Physical Design Logical Design AnalysisProject Identification and Selection Project Initiation J.A. Hoffer, J.F. George, and J.S. Valacich, Modern Systems Analysis and Design, Reading, Massachusetts: Addison Wesley, Steps of a Systems Analysis and Design Life Cycle (SDLC) I. The Analysis Phase – determining systems requirements and structuring the requirements by creating process models, logical models, and conceptual data models. II. The Logical Design Phase – developing the logical design of the database and designing forms, reports, interfaces, and dialogues. III. The Physical Design Phase – designing physical files, databases, and programming instructions. IV. The Implementation and Maintenance Phase – performing system coding, testing, installing, documenting, user training, supporting users, and maintaining the system.

The Systems Development Process J.L. Whitten, L.D. Bentley, and V.M. Barlow, Systems Analysis and Design, instructors ed., 3rd ed. Burr Ridge, Ill.: Richard D. Irwin, Systems Planning Planned application development process Systems Analysis Business requirements statement Systems Design Technical design statement Existing system details and limitations Systems Support Existing system details and limitations Systems Implementation Production information system

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Phase 1: Systems Analysis n Step 1-A: Defining systems requirements n Step 1-B: Structuring systems requirements using process modeling n Step 1-C: Structuring systems requirements using logical models n Step 1-D: Structuring systems requirements using conceptual data modeling n Step 1-E: Selecting a design strategy

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill STEP I-A: Systems Analysis - Defining Systems Requirements n After an organization has: ä identified the need for a system project and ä has successfully made a business case to justify investing the time and funds necessary to undertake the project, ä a project team organizes and plans the work to be completed. n The team considers the costs, benefits, feasibility, responsibilities, and project timeline. n After completing these details they define the system requirements: ä What are the expectations of this system? ä What work and decisions will it support? ä What objectives will it help the organization to accomplish?

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Defining Systems Requirements n Your business analysis highlights the activities that an organization needs to perform effectively and efficiently to accomplish its objectives. n An information system should support these activities. n Add information processes, including data stores, and data flows, to the analysis n Consider the desired environment and envision innovative ways for the system to enable organization objectives and desired processes.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Recording operating event data Maintaining reference data about resources, agents, and locations Exhibit 4-3 Christopher Inc. REAL Model Resources Events Agents Order personnel Customer Inventory Receive customer order includes takes places Cashier Collect payment CashBank is kept at increases takes in sends Shipping personnel Shipping firm Ship Order is made up of goes to executes carried by Christopher Inc. provides baseball caps to major league baseball teams to sell in their ballparks. While analyzing their business process, Christopher’s analysis team identified three key operating activities: receive orders from baseball teams (who are Christopher’s customers), package and ship caps to the teams (the sale of merchandise), and receive payment from the teams Reporting useful information to information customers

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill The Structure of Information Processes Recording Process Stimulus Response Notification Data  Executing each operating event triggers the need to record descriptive data about the event.  When data is captured while the operating event occurs, the recording process can execute business rules specified by management for each operating event.  These rules are the guidelines, standards, policies, and/or procedures intended to increase operational and information quality by reducing such problems as errors, irregularities, or fraud. Ideally, the execution of the operating event and the related information process occur simultaneously. Maintaining Process Stimulus Response Notification Data  To support a business process, a system must collect data about the resources, agents, and locations that define the operating events. The system must allow the data to be kept current.  Maintaining reference data involves adding, deleting, or modifying data about resources, agents, and locations (e.g., changing products offered by a vendor; changing an employee's marital status; and adding a new vendor to the vendor list).  The objective is to maintain accurate, complete, and timely data about the resources, agents, and locations involved in operating events for the process you are modeling. Reporting Process Stimulus Data Response Notification  The reporting processes extract and convert stored data about events, resources, agents, and locations into information, and formatting the information for presentation to information customers.  These views often consist of financial and performance measures and may take the form of hardcopy source documents, hardcopy reports, electronic data flows, or ad hoc queries.  These data flows authorize actions, provide documentation to other business functions or to outside parties, and support both operational and strategic decision making.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill STEP I-B: Systems Analysis - Structuring Systems Requirements Using Process Modeling n Some analysis methods create several versions of data flow diagrams, including ä context data flow diagrams, ä data flow diagrams of the current physical system, data flow diagrams of the current logical system, and ä data flow diagrams of the proposed logical system. n Often, each data flow diagram includes a thorough description of each data flow.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-4 Christopher Inc., Context Diagram O Sales / collection system Christopher Inc. needs a system that enables communication with customers several times during the process (e.g., customers send in order data as well as payment data, and Christopher Inc. sends back shipping, sales, billing, and payment data). Customers Order Shipping/Bill Payment Decision Makers Desired Information Christopher Inc. needs a system that allows them to send shipping data to their carriers and receive shipment confirmations from their carriers. Carriers Shipping Data Confirmation Finally, Christopher Inc.’s systems should allow access by internal agents (such as management and other decision-makers) to critical data and information. the circle represents computer processing  A context diagram shows the sources and destinations of the data that are outside the boundaries or scope of the system being analyzed.  You do not show the data stores and data flows within the boundaries of the system.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-5 Christopher, Inc. Level 0 Data Flow Diagram 1.0 Process customer orders 2.0 Process shipments to customers 3.0 Process payments from customers Customers Decision makers Orders Bill Payment Desired information Shipping request data Payments due data Desired information Desired information

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-6 Christopher Inc., Level 1 Data Flow Diagram 1.1 Approve and record customer order data Customer order data 1.2 Generate informatio n about orders Order Approved Order Order data Shipping Request Data Desired information

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Context Dictionary n Some analysts like to add more detail to context and other data flow diagrams, by providing the data elements that comprise the data flows on the diagram. We will refer to these data flow details as the context dictionary. Each entry in the context dictionary is separated from its definition by an equal sign (=) and is defined using the following set of symbols: – +To connect elements of the definition – {}To identify repeating elements of the definition

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Sample Context Dictionary Entries n Sales-Invoice = Invoice # + Sale-Date + Register # + Customer Name + Salesperson Name + {Merchandise Name + Qty-Sold + Price + Item-Total} + Sale-Total n Customer-Profile = Report-Date + Name + State + Birth date + Telephone + {Merchandise Description + Qty-Sold} n Product-Sales = Report-Date + {Merchandise # + Merchandise Description + Qty-Sold + %Margin + $ Contribution} n Accounting-Revenue = Report-Date + Reporting-Period + Revenue for Reporting-Period n Sales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description + Qty-Sold + $ Contribution} + Total Sales + Total Contribution

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill When you are creating data flow diagrams or work-flows for a business process, how do you know how many recording, maintaining, and reporting processes you need for an IT application? You can use your REAL model and the context diagram as a guide. context diagram inflows and outflows to Record event data Maintain resource, agent, location data Report source documents, queries, reports You need one recording process in your IT application for each business event object in the application’s REAL model You need one maintenance process in your IT application for each resource, agent, and location object in the application’s REAL model The number of reporting processes required for an application is a function of the number of views required by information customers. You will need one reporting process for each required output view. To help you plan, determine how many of the following three types of reporting output views your information customers need: - Source documents: printed or electronic transmission of event data documentation - Preformated reports: reports that are regularly used by information customers -Ad hoc reports: reports that information customers design and request to provide a new view or a view that is rarely used The number of reporting processes required for an application is a function of the number of views required by information customers. You will need one reporting process for each required output view. To help you plan, determine how many of the following three types of reporting output views your information customers need: - Source documents: printed or electronic transmission of event data documentation - Preformated reports: reports that are regularly used by information customers -Ad hoc reports: reports that information customers design and request to provide a new view or a view that is rarely used Additional Prototyping Steps

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill McKell's Retail Sale Store Case Checkpoint Using our retail sale example, the IT application would have: One recording process (i.e., Record Sale Data) to record the one event of interest Four maintenance processes Maintain Customer Data, Maintain Merchandise Data, Maintain Salesperson Data, and Maintain Register Data to keep our resource, agent, and location data up to date and valid Reporting processes to handle key management functions: Sales Invoice - the customer's bill; Customer Profile - a report that provides information about customers and their purchasing habits; Product Sales - a report that provides the margin and contribution for each merchandise items type sold; Accounting Revenue - a report that provides a calculation of sales revenue for a specific period; Sales by Salesperson - a report that details the merchandise and contribution to sales revenue for each salesperson)

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Step 1-C Structuring Systems Requirements Using Logical Models n After completing data flow diagrams that graphically show the flow of data to fulfill the system requirements, many analysts use logic models to represent the logic of the information processes denoted in the data flow diagram(s). n Their objective is to produce structured descriptions and diagrams that enumerate the logic contained in each process denoted in the data flow diagram(s). n Techniques used during this step include structured English, decision tables, decision trees, and state-transition diagrams or tables. n We will overview just one of these techniques: Structured English.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Structured English n Structured English is used to plan and document the steps of a computer instruction set (a program) without using a programming language. Structured English is used to define the detailed logic of each information process (Exhibit 4-7). n Structured English focuses on conciseness and clarity to document the essence of an information process and eliminates: ä Adjectives. ä Adverbs. ä Compound sentences. ä Non-imperative expressions. ä All but a limited set of conditional and logic structures. ä Most punctuation. ä Footnote type details.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-7 Structured English Example Process Input Output Data For each Customer-Order do the following: 1. Search for Customer-Name if found Confirm customer info with customer if not found Enter customer data 2. Check for availability of inventory requested if available Confirm ship-to-information if not available Inform customer with Order-Confirmation 3. Provide customer with Order-Confirmation 4. Send notification to packing agents

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Business Event Risks n In addition to including the logic for completing a desired task, this step provides an opportunity for thinking about ways information technology can be used to help reduce business and information risks ä An operating event occurring at the wrong time or sequence. ä An operating event occurring without proper authorization. ä An operating event involving the wrong internal agent. ä An operating event involving the wrong external agent. ä An operating event involving the wrong resource. ä An operating event involving the resource amount. ä An operating event occurring at the wrong location.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Information Event Risks n Information event risks include the risks associated with incomplete, inaccurate, or unauthorized recording, maintaining, and reporting information activities: ä Recording risks - Recording risks include recording incomplete, inaccurate, or invalid data about an operating event. Incomplete data results in not recording all of the relevant characteristics about an operating event in the data stores. Inaccuracies arise from recording data that does not accurately represent the event. Invalid refers to data that are recorded about a fabricated event. ä Maintaining risks - Maintaining risks are essentially the same as recording risks. The only difference is that the data maintained relates to resources, agents, and locations rather than operating events. ä Reporting risks - Reporting risks include data that are improperly classified, improperly summarized, provided to unauthorized parties, or not provided in a timely manner.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill STEP I-D: Systems Analysis: Structuring Systems Requirements Using Conceptual Data Modeling n To focus on the specific data you want to capture to describe reality and generate needed outputs we use a conceptual data model. n Conceptual data models represent the entities or objects you want to collect data about, and rules about the meaning and interrelationships among these data objects. n To complete this step, most analysts use one of two modeling techniques: Entity-Relationship (E-R) or Object Oriented (OO).

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Entity Name Relationship Name ERD n Data Entity ä anything, real or abstract, about which we want to store data. ä synonyms include entity type, entity class or object n Data relationship ä a natural association that exists between one or more entities ä business activities or events that link one or more entities

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Example Customer Places/ or Is Placed By Orders Contains or Is Contained By Supplies

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Entities n AGENTS n Entities that describe roles played in a system. They usually represent people or organizations. ä ACCOUNT, AGENCY, ANIMAL, APPLICANT, BORROWER, CHILD, CLASS, CLIENT, CONTRACTOR, CREDITOR, DEPARTMENT, EMPLOYEE, EMPLOYER, INSTRUCTOR, MANAGER, OFFICE, SALESPERSON, SUPPLIER, TEAM, VENDOR

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Entities n RESOURCES n Entities that describe tangible things. Most tangible things are easy to identify because you can see them. ä BOOK, CHEMICAL, COURSE, DISK, EQUIPMENT, MACHINE, MATERIAL, METAL,PART, PRODUCT, PROGRAM, SERVICE, SUBSTANCE, VEHICLE

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Entities n EVENTS n Most events are easy to identify because the business records data on forms or files. n Events are characterized by the fact that they happen or have duration ä AGREEMENT, APPLICATION, APPOINTMENT, ASSIGNMENT, BACKORDER, BUDGET, CLAIM, CONTRACT, DEPOSIT, DISBURSEMENT, FORECAST, INVOICE, JOB, LICENSE, PAYMENT, PURCHASE ORDER, REGISTRATION, RESERVATION, RESUME, SEMESTER, SHIPMENT, STEP, TASK, TEST, WORK ORDER

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Entities n LOCATIONS n Entities that describe locations ä BRANCH, BUILDING, CAMPUS, CITY, COUNTRY, COUNTY, ROOM, ROUTE, SALES REGION, SCHOOL ZONE, PROVINCE, STORAGE BIN, VOTER DISTRICT, WAREHOUSE ZONE

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Entities and Entity Classes or Groups n Entities of a given type are grouped into an entity class n Thus, the EMPLOYEE entity class is the collection of all EMPLOYEE entities n Entity classes are described by their structure n An instance of an entity is the representation of a particular entity such as Customer 1234 and is described by its values of the attributes n Name entities with nouns that describe above (singular) INVOICE n Instances of the entity are referred to in the plural - Invoices

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Attributes n Data attributes are characteristics that are common to all or most all instances of a particular entity. n Synonyms include: properties, data elements, descriptors, and fields n Attributes take on values for each occurrence of an entity. An attribute must have more than one legitimate value otherwise it is a constant.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Identifier n Identifier is an attribute or combination of attributes that uniquely identifies one, and only one occurrence of an entity. n Synonyms include key or primary key ä For example, Employee instances could be identified by a SocialInsuranceNumber, EmployeeNumber or EmployeeName ä Identifiers of an entity instance consists of one or more of the entity’s attributes ä An identifier may be either unique or non-unique ä Identifiers that consist of two or more attributes are called composite identifiers

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Relationships n Entities can be associated with one another in relationships. n A relationship can include many entities; and the number of entities in a relationship is a degree of the relationship. ä Degree 2 relationships are common and are called binary relationships ä 1:1 one to one AUTO-ASSIGNMENT ä 1:N one to many DORM-OCCUPANT ä N:M many to many STUDENT-CLUB

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Relationship Degree SALESPERSON ORDER SP-ORDER Degree 2 MOTHER FATHER CHILD PARENT Degree 3

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Three Types of Binary Relationships EMPLOYEE AUTO AUTO-ASSIGNMENT 1:1 DORMITORY STUDENT DORM-OCCUPANT 1:N STUDENT CLUB STUDENT-CLUB N:M These are often called HAS A relationships These are often called HAS A relationships Shows MAXIMUM cardinality Shows MAXIMUM cardinality may or may not must exist

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Other relationships DORMITORY STUDENT DORM-OCCUPANT 1:N Minimum cardinality Recursive relationship STUDENT 1:N ROOMS-WITH EMPLOYEE DEPENDENT 1:N Weak Relationships BUILDING APARTMENT 1:N ID Dependent entity

ERD: CUSTOMER SALESPERSON SALES-ORDER LINEITEM ITEM I:N N:1 I:N Semantic Object Model (SALSA)

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Access Database Relationships

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill REAL Diagram Customer (Agent) Take Order (Event) Take Order (Event) SalesPerson (Agent) SalesPerson (Agent) Product-Item (Resource) Product-Item (Resource) List Items Ordered (Event) (1,1) (1,*) (1,1) (0,*) CUSTOMER (Customer#, CustomerName, Street, City, State, Zip) SALESPERSON (SalesPerson#, SalesPersonName) SALES-ORDER (Order#, Date, [Customer#], [SalesPerson#],Subtotal, Tax, Total) ITEM (Item#, Name, Description) (LineItem#, [Order#],Quantity, [Item#], ExtendedPrice) ITEMS-ORDERED

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-8 Recursive Relationship Example Employee manages Employee manages

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Relationships n Described by verbs or verb phrases n Multiple relationships are possible between two entities COURSESTUDENT Was Taken by Is Being Taken by

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Ordinality n Defines whether the relationship between entities is mandatory or optional. n Ordinality determines the minimum number of occurrences of one entity relative to another. n Ordinality must be defined in both directions

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Cardinality n Defines the maximum number of occurrences of one entity for a single occurrence of the related entity n This is the number to the right of the colon below. Ordinality is the number to the left of the colon. Customer Places Order Contains Products 1:1 0:M 1:M

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Relationships That Can Be Described by Data n Normally relationships are not described by data attributes n However if Cardinality is many in both directions, the relationship itself is frequently described by data attributes. n “Many to Many” relationship n An associative entity is a data entity whose attributes describe a relationship between two or more fundamental entities

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Ordered Product Many to Many Service Product Order Is Placed For Shipment Invoice Requested Service 1:M OR 0:M AND 1:1 0:M

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Create a separate table that includes the key attributes from both object tables. Create a separate table that includes the key attributes from both object tables. Linking Objects with Many to Many (*:*) Relationships

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Linking Objects with One to One (1:1) Relationships Put the key attribute of either object in the table of the other Put the key attribute of either object in the table of the other Create a separate table that includes the key attributes from both objects Create a separate table that includes the key attributes from both objects When you are linking two events with a 1:1 relationship, either put the key of the prior event table into the subsequent event table or create a third table. OR

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Post the key attribute of the object with the 1 side of the cardinality into the table of the many (*) side of the cardinality. Post the key attribute of the object with the 1 side of the cardinality into the table of the many (*) side of the cardinality. If you follow the specified rule and find that you would post the key of the event that occurs second into the table of the event that occurs first, create a separate table that includes the key attributes from both event tables. Linking Objects with One to Many (1:*) or Many to One (*:1) Relationships

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-9 Christopher Inc. REAL Model Resources Events Agents Order personnel Customer Inventory Receive customer order includes takes places Cashier Collect payment CashBank is kept at increases takes in sends Shipping personnel Shipping firm Ship Order is made up of goes to executes carried by (1,*) (0,*) (1,1)

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-10 Different Notations to Represent Relationships Cardinalities (1,1) (1,*) (0,1) (0,*)

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-11 Entity Attributes in an ER diagram Inventory Item # Inventory Item # Inventory Item # Inventory Item # Inventory Item # Inventory Item # Inventory Item #

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-12 Example Relational Database Table Customer Table

SALES table (without a separate table for the sale-inventory *:* relationship):

Sales Event Table (*:*) Sale-Inventory Table

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-13 Christopher Inc. Event Logical Structures - Order Taking CUSTOMER Customer #, Name, Street Address, City, State, Zip, Telephone# Credit Rating, Credit Limit RECEIVE CUSTOMER ORDER Sales Order #, [Customer #], [Customer Order Representative Employee #], Date, Time, Instructions, Cancel by Date, Location or order EMPLOYEE, Employee #, Name, Address Telephone #, BirthDate Start date, Salary, ORDER/INVENTORY [Sales Order #], [Inventory item #], Quantity Ordered INVENTORY Inventory Item #, Description, Product Specification, Reorder Point, Current Price, Beginning Quantity, Beginning Quantity Date Legend RELATION Primary Key [Foreign Key]

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-13 Christopher Inc. Event Logical Structures - Shipping SHIP ORDER Invoice #, [Sales Order #], [Customer #], [Shipping Personnel Employee #], [Shipping Firm ID #], Date, Time, Shipment tracking #, Sales Tax SHIPPING FIRM, Shipping Firm ID#, Shipping Firm Name, Address Telephone #, Contact Person Rate Information SHIP/INVENTORY [Invoice #], [Inventory Item #], Quantity Shipped, Price Each Inventory Customer Employee Sales Order

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill BANK Bank #, Bank Name, Address COLLECT PAYMENT Cash Receipt #, [Cash Account #], [Customer #], [Cashier Employee #], Date, Time, Amount Received, Electronic Funds Transfer # Exhibit 4-13 Christopher Inc. Event Logical Structures - Cash Collection SHIP/COLLECT PAYMENT [Invoice #], [Cash Receipt #], Amount applied to this Invoice CASH Cash Account #, [Bank #], Type of Account Beginning Balance Date Customer Employee Shipping Order

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-14 Linking the Order Recording Process with the Data Repository Record Sale Order-Data INVENTORY ORDER CUSTOMER ORDER PERSONNEL ORDER-INVENTORY

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-15 Sample Maintenance Processes and Data Access Update Bank Data Register-Data Update Customer Data Customer-Data Update Shipping firm Data Salesperson-Data Update Inventory Data Merchandise-Data INVENTORY BANK CUSTOMER SHIPPING FIRM

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-16 Example fo Generating a Sales-by-Salesperson Report Report Sale Request Sales-by- Salesperson report MERCHANDISE Sales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description + Qty-Sold + $ Contribution} Total Sales + Total Contribution Sales-by- Salesperson SALE SALESPERSON SALE-MERCHANDISE

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Exhibit 4-17 Evolution Of AIS Modeling Stage 1 Manual Systems Stage 2 Automated Systems Stage 3 Resources: Manual Process: Acct Cycle Data Stores (Files): Journals & Ledgers Resources: Information Technology Process: Acct Cycle Data Stores (Files): Journals & Ledgers Event Driven IT Applications Resources: Information Technology Process: Record, Maintain, Report Business Activity Data Data Stores: Business Activity Data Integrated Stores Bias: Generate financial statements Bias: Generate financial statements Bias: Support Planning, Control & Evaluation Activities of Various Information Customers

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Prototyping: Preliminary Steps Step 1: Review the business process and identify the business events of interest.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Prototyping: Preliminary Steps Step 1: Review the business process and identify the business events of interest. Step 2: Analyze each event to identify the event resources, agents, and locations.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Prototyping: Preliminary Steps Step 1: Review the business process and identify the business events of interest. Step 2: Analyze each event to identify the event resources, agents, and locations. Step 3: Identify the relevant behaviors, characteristics, and attributes of the event, resources, agents, and locations.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Prototyping: Preliminary Steps Step 1: Review the business process and identify the business events of interest. Step 2: Analyze each event to identify the event resources, agents, and locations. Step 3: Identify the relevant behaviors, characteristics, and attributes of the event, resources, agents, and locations. Step 4: Identify the direct relationships between objects.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Prototyping: Preliminary Steps Step 1: Review the business process and identify the business events of interest. Step 2: Analyze each event to identify the event resources, agents, and locations. Step 3: Identify the relevant behaviors, characteristics, and attributes of the event, resources, agents, and locations. Step 4: Identify the direct relationships between objects. Step 5: Validate the model with the business person.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Planning an Event-Driven Application ¶ Identifying the business events of interest · Identifying the resources, agents, and locations of each event of interest ¸ Identifying the relevant behaviors, characteristics and attributes of the events, resources, agents, and locations ¹ Identifying the direct relationship between objects º Validating your business process model with business persons Chapter2Chapter2 Chapter2Chapter2

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Planning an Event-Driven Application » Defining the scope of the IT application ¼ Enhancing the relationships of the REAL model by defining their cardinalities ½ Designing the data repository ¾ Linking the recording, maintaining, and reporting process to the data repository ¿ Constructing the prototype Chapter4Chapter4

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill McKell’s Retail Sale Store Sale Customer Merchandise Salesperson Register

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Application Context Diagram EVENT-DATA Definitions of various data flows for each business event within the application scope MAINTENANCE-DATA Definitions of various data flows for maintaining application reference data RESPONSES Definitions of various responses provided by the application NOTIFICATIONS Definitions of various notifications provided by the application REPORTS Definitions of various reports provided by the application Event-Data Reports Application Context Response Notification Maintenance-Data

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill McKell’s Retail Sale Context Diagram EVENT-DATA Example= Sale-Data = Sale-Date + Register # + Customer # + Employee # + {Merchandise # + Qty-Sold} MAINTENANCE-DATA Example= Definitions of various data flows for maintaining customer, salesperson, and register reference data RESPONSE Example= Sales-Invoice = Invoice# +Sale-Date + Register # + Customer Name + Salesperson Name + {Merchandise Name + Qty-Sold + Price + Item-Total} + Sale-Total NOTIFICATION Example = Warehouse-notification = Invoice#+{Merchandise# + Qty-Sold} REPORT Example = Product-Sales = Report-Date + {Merchandise # + Merchandise Description + Qty-Sold + %Margin + $ Contribution} Accounting-Revenue = Report-Date + Reporting-Period + Revenue for Reporting-Period Sales-by-Salesperson = Report-Date + {Salesperson Name + {Merchandise-Description + Qty-Sold + $ Contribution} Total Sales + Total Contribution Customer-Profile = Report-Date + Name + State + Birthdate + Telephone + {Merchandise Description + Qty-Sold} Event-Data Reports Application Context Response Notification Maintenance-Data

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Additional Prototyping Steps: Step 6: Define the scope of the application. Step 7: Enhance the relationships of the REAL model by defining their cardinalities. object 1(min, max) --- object 2(min, max) minimums denote business rules maximums help establish data structures both help structure your audit trail

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill McKell’s Retail Sale REAL Model With Cardinalities Sale Customer Merchandise Salesperson Register (1,1) (0,*) (1,1) (0,*) (1,1) (1,*) (0,*)

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Additional Prototyping Steps: Step 6: Define the scope of the application. Step 7: Enhance the relationships of the REAL model by defining their cardinalities. Step 8: Design the data repository structure. tables or objects primary keys posted keys nonkey attributes

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill McKell’s Retail Sale Store - Tables Register(Register#, Merchandise(Merchandise#, Sale(Sale#, Customer(Customer#, Salesperson(Employee#, Sale-Merchandise([Sale#], [Merchandise#],

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill McKell’s Retail Sale Store - Tables Register(Register#, Merchandise(Merchandise#, Sale(Sale#, [Register#], [Customer#], [Employee#], Customer(Customer#, Salesperson(Employee#, Sale-Merchandise([Sale#], [Merchandise#],

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill McKell’s Retail Sale Store - Tables Register(Register#, Store, Date-Purchased, Cost,... Merchandise(Merchandise#, Description, Current-Price, Current-Cost,... Sale(Sale#, [Register#], [Customer#], [Employee#], Time,... Customer(Customer#, Name, Address, State, Zip, Birthdate, Telephone#, Marital-Status,... Salesperson(Employee#, Name, Commission-Rate,... Sale-Merchandise([Sale#], [Merchandise#], Qty-Sold, Historical-Cost, Historical-Price,...

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Additional Prototyping Steps: Step 6: Define the scope of the application. Step 7: Enhance the relationships of the REAL model by defining their cardinalities. Step 8: Design the data repository structure. Step 9: Link the recording, maintenance, and reporting processes to the data repository. Record events Maintain resources, agents, and locations Report (source documents, queries, reports)

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Additional Prototyping Steps: Step 6: Define the scope of the application. Step 7: Enhance the relationships of the REAL model by defining their cardinalities. Step 8: Design the data repository structure. Step 9: Link the recording, maintenance, and reporting processes to the data repository. Step 10: Build the application prototype.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill McKell’s Retail Sale Updated REAL Model With Cardinalities Sale Customer Merchandise Salesperson Register (1,1) (0,*) (1,1) (0,*) (1,1) (1,*) (0,*) Receive Payment Receipts Clerk Cash (0,*) (1,1) (0,*) (1,1) Store (1,1) (0,*) (1,*)

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill McKell’s Retail Sale Store Tables: Merchandise Customer Salesperson Sale-Merchandise Register We are able to satisfy multiple views by the data we collect : What happened? When? What resources were involved and how much? Where did it occur? Who was involved and what roles did they play? Sale

Steps for Building an IT Application Prototype 1. Build a table for each table defined using the REAL model, 2. Build a menu system that has the following choices: Record Event Data, Maintain Data, Reports, and Exit. 3. Develop the necessary forms and procedures to collect event data and store it in the appropriate tables. 4. Develop the necessary forms and procedures to maintain the resource, agent, and location tables. 5. Develop queries required to generate desired information. 6. Develop report formats for each report. 7. Write the procedures required to execute the queries and format the reports. 8. Link each recording, maintaining, and reporting form to the application menu defined in step 2. Each form becomes a choice under either the Record Event Data, Maintenance, or Reports menu options.

 The McGraw-Hill Companies, Inc., 2000 Irwin/McGraw-Hill Customer Places Order Package and Deliver Product Receive Payment Salesperson Product Components Packager Carrier Customer Customer Payment Clerk Cash Package Customer Service Center Distribution Center Customer Returns Merchandise Returns Clerk REAL Business Process Modeling of Mail Order Sales/Collection Process