IS 421 Information Systems Analysis James Nowotarski 7 October 2002

Understand basics of data modeling: –Defining entities –Defining attributes –Defining relationships –Drawing entity-relationship diagrams (ERDs) Today’s Objectives

Course Map Contents 1. Introduction Planning Phase 2. Project Initiation 3. Project Management Analysis Phase 4. Systems Analysis 5. Gathering Information 6. Process Modeling 7. Data Modeling Assignments Quizzes Final Week Core Exam Review

Topic Duration Recap Last Week20 minutes Recap Assignments minutes Quiz45 minutes *** Break15 minutes Data Modeling: Lecture/Discussion45 minutes Data Modeling: Group Exercises45 minutes Assignment 3 Intro10 minutes Today’s agenda

Topic Duration Recap Last Week20 minutes Recap Assignments minutes Quiz45 minutes *** Break15 minutes Data Modeling: Lecture/Discussion45 minutes *** Bears vs. Packers begins Data Modeling: Group Exercises45 minutes Assignment 3 Intro10 minutes Today’s agenda

Topic Duration Recap Last Week20 minutes Recap Assignments minutes Quiz45 minutes *** Break15 minutes Data Modeling: Lecture/Discussion45 minutes Data Modeling: Group Exercises45 minutes Assignment 3 Intro10 minutes Today’s agenda

SDLC The systems development life cycle (SDLC) is a description of the phases of an information system PlanningAnalysisDesign Implementation

Key Definitions The As-Is system is the current system and may or may not be computerized The To-Be system is the new system that is based on updated requirements

Analysis Phase

From Planning Phase: System request Feasibility analysis Workplan. Dev Analysis Plan Examine- As-is Identify Improve- ments Develop Basic System Concepts Develop Data Model Develop Process Model Prepare Proposal To Design Phase: Deliverables: Analysis PlanFunctional Requirements Quality Requirements System Concept Data Model Process Model System Proposal Develop Concept for To-Be System

Analysis Phase From Planning Phase: System request Feasibility analysis Workplan. Dev Analysis Plan Examine- As-is Identify Improve- ments Develop Basic System Concepts Develop Data Model Develop Process Model Prepare Proposal To Design Phase: Develop Concept for To-Be System GatherAnalyze Specify

Three Fundamental Analysis Strategies Business process Automation (BPA) Business Process Improvement (BPI) Business Process Reengineering (BPR)

High-Level Work Plan for Analysis

Begin with the End in Mind Table of contents Executive summary System request Work plan Analysis strategy Recommended system Feasibility analysis Process model Data model Appendices System Proposal Outline

Information Gathering Techniques Interviewing Joint application design Questionnaires Document Analysis Observation

Interviews -- Five Basic Steps Selecting Interviewees Designing Interview Questions Preparing for the Interview Conducting the Interview Post-Interview Follow-up

Types of Questions Examples Closed-Ended Questions* How many telephone orders are received per day? * How do customers place orders? * What additional information would you like the new system to provide? Open-Ended Questions* What do you think about the current system? * What are some of the problems you face on a daily basis? * How do you decide what types of marketing campaign to run? Probing Questions* Why? * Can you give me an example? * Can you explain that in a bit more detail?

Interview Report INTERVIEW REPORT Interview notes approved by: ____________ Person interviewed ______________ Interviewer _______________ Date _______________ Primary Purpose: Summary of Interview: Open Items: Detailed Notes:

JAD Key Ideas Allows project managers, users, and developers to work together May reduce scope creep by 50% Avoids requirements being too specific or too vague

Joint Application Design (JAD) Important Roles Facilitator Scribe

JAD Meeting Room JPEG Figure 5-5 Goes Here

Questionnaire Steps Selecting participants –Using samples of the population Designing the questionnaire –Careful question selection Administering the questionnaire –Working to get good response rate Questionnaire follow-up –Send results to participants

Document Analysis Provides clues about existing “as-is” system Typical documents –Forms –Reports –Policy manuals Look for user additions to forms Look for unused form elements

Observation Users/managers often don’t remember everything they do Checks validity of information gathered other ways Behaviors change when people are watched Careful not to ignore periodic activities –Weekly … Monthly … Annual

Selecting the Appropriate Techniques Interviews JAD Questionnaires Document Observation Analysis Type of As-Is As-Is As-Is As-Is As-Is Information Improve. Improve. Improve. To-Be To-Be Depth of High High Medium Low Low Information Breadth of Low Medium High High Low Information Integration Low High Low Low Low of Info. User Medium High Low Low Low Involvement Cost Medium Low- Low Low Low- Medium Medium

Summary There are five major information gathering techniques that all systems analysts must be able to use: Interviews, JAD, Questionnaires, Document Analysis, and Observation. Systems analysts must also know how and when to use each as well as how to combine methods.

Topic Duration Recap Last Week20 minutes Recap Assignments minutes Quiz45 minutes *** Break15 minutes Data Modeling: Lecture/Discussion45 minutes Data Modeling: Group Exercises45 minutes Assignment 3 Intro10 minutes Today’s agenda

Topic Duration Recap Last Week20 minutes Recap Assignments minutes Quiz45 minutes *** Break15 minutes Data Modeling: Lecture/Discussion45 minutes Data Modeling: Group Exercises45 minutes Assignment 3 Intro10 minutes Today’s agenda

Topic Duration Recap Last Week20 minutes Recap Assignments minutes Quiz45 minutes *** Break15 minutes Data Modeling: Lecture/Discussion45 minutes Data Modeling: Group Exercises45 minutes Assignment 3 Intro10 minutes Today’s agenda

Data Modeling in the Analysis Phase From Planning Phase: System request Feasibility analysis Workplan. Dev Analysis Plan Examine- As-is Identify Improve- ments Develop Basic System Concepts Develop Data Model Develop Process Model Prepare Proposal To Design Phase: Deliverables: Analysis PlanFunctional Requirements Quality Requirements System Concept Data Model Process Model System Proposal Develop Concept for To-Be System

Key Definitions A data model is a –Formal representation of the data to be used for a business system. A data model should illustrate: –The people, places and things about which data is collected, –And how they are related to each other

Key Definitions A logical data model shows the logical organization of data –Without regard for how data gets stored, created or manipulated A physical data model shows how the data will physically be stored in the database (secondary memory). –E.g. Oracle may store a customer table in several files (cust1.dbf, cust2.dbf…) that span several hard drives.

Key Definitions Logical data model (Wixom and Dennis) Data model Conceptual data model Entity model Entity-relationship model Entity-attribute-relationship model Information model Semantic data model The collective output from logical data modeling is called various names

Data Modeling Entity-relationship diagram (ERD) Entity descriptions Attribute descriptions Relationship descriptions Domain descriptions (not covered here) A logical data model deliverable includes an ERD and descriptions of entities, attributes, and relationships Components of a Logical Data Model

An ERD Example

Entities generally represent people, places, and things of interest to the organization (about which we would like to collect data). Represented as rectangle on the ERD Named with a singular noun (e.g., Patient) What Is an Entity?

Entities and Instances Instances are occurrences of an entity

What is an Attribute? An attribute is a characteristic or property of an entity. Attributes contain information that describes an entity. Attribute names are nouns (e.g, “name”). Sometimes entity name is added at the beginning of the attribute name (e.g., “vendor_name”).

Examples of Attributes Entity: Person –Attributes: first_name last_name eye_color date_of_birth address Entity: Classroom –Attributes: room_no max_capacity

An ERD Example

Identifiers An identifier uniquely identifies each instance of the entity. It may consist of one or more attributes. Identifiers are also known generically as keys –Candidate keys = all identifiers for an entity –Primary key = candidate key designated as “official” identifier

Examples of Identifiers What attribute uniquely identifies every instance of these entities? –Student –Classroom –Vehicle

Depicting Entities, Attributes and Identifiers Entity name Attributes Identifier Or, use cd_id (PK)

An ERD Example

Relationships Relationships represent connections, links, or associations between entities e.g., Patient-Appointment Relationships have some important properties: 1.Names, that should be active verbs –(A patient schedules appointments) 2.Cardinality 3.Modality.

Cardinality Cardinality refers to the number of times instances in one entity can be related to instances in another entity –One instance in an entity refers to one and only one instance in the related entity (1:1) –One instance in an entity refers to one or more instances in the related entity (1:M) –One or more instances in an entity refer to one or more instances in the related entity (M:M)

Modality Modality refers to the minimum number of times that an instance in one entity can be related to an instance in another entity –One means that an instance in the related entity must exist for an instance in another entity to be valid –Zero means that no instance in the related entity is necessary for an instance in another entity to be valid

Some Ways to Depict Relationships PatientAppointment PatientAppointment PatientAppointment PatientAppointment 1M schedules Is scheduled by Same e.g., A patient may have zero to many appointments

Meanings of the Crow’s Feet Min Max Cardinality 011 0M[any] 1M[any]

The Entity-Relationship Diagram (ERD)

An ERD Example

What Is an ERD? A picture of the logical data model, –i.e., an ERD shows the information created, stored, and used by a business system.

An ERD Example A patient must have at least 1 appointment

Topic Duration Recap Last Week20 minutes Recap Assignments minutes Quiz45 minutes *** Break15 minutes Data Modeling: Lecture/Discussion45 minutes Data Modeling: Group Exercises45 minutes Assignment 3 Intro10 minutes Today’s agenda

Exercise SkyHigh Airlines has three major resources: airplanes, pilots, and crew members. Pilots and crew members have home bases, which they return at the end of an assigned flight. A flight must have exactly one pilot and one or more additional crew members along with an airplane. Each airplane has a maintenance base. Draw an ERD showing: Entities Relationships Cardinality Modality 10 minutes

Group Exercise Textbook, p.209, Exercise D-1 Show: Entities Attributes Identifier(s) Relationships Cardinality Modality 15 minutes

Still More Definitions A foreign key is all of these things: a primary key of one entity (sometimes called parent entity), duplicated in another entity (child entity) provides a common linkage between the two entities

Foreign Key Example Customer(cust_id (PK), cust_name) Order (ord_no (PK), cust_id (FK), ord_date) Customers (Parent) cust_id cust_name 100Slick Willy, Inc. 200George_W, Co. 300Gore, Ltd. … ord no cust_idord_date Sep Nov Dec Dec-2000 … Orders (Child) A foreign key is a primary key of one entity that is duplicated in another entity to provide a common linkage between entities. Why use them? PK FKCust_id

Entity Types 1.Independent 2.Dependent 3.Intersection

Independent Entities An independent entity exists without the help of another entity –Common entities such as student, professors, customers, products –The identifier is created by the entity’s own attributes –Usually on the “1” side of a relationship –a.k.a. fundamental entity (in Visual Analyst, e.g.) or strong entity

Dependent Entities Alternatively, a dependent entity cannot exist without the help of another entity –Special entities such as emp_dependent (needs an employee to exist) –The identifier is usually based on another entity’s attributes (emp_ssn & dep_ssn) –Usually on the “M” side of a relationship –a.k.a. attributive entity (in Visual Analyst, e.g.) or weak entity

Intersection entities An intersection entity exists based on the relationship between two entities. –They have attributes that are peculiar to the relationship between those entity instances, not the individual entities themselves –They are created to store information about two entities sharing an M:M relationship –a.k.a. associative entities, gerunds

Intersection Entity Example A student may take many classes. A class may have many students. Where are grades stored? Student Class An instance in the student entity is related to _____ instances in the class entity. An instance in the class entity is related to _____ instances in the student entity. RosterStudentClass

An ERD Example: CD’s Relationships Expanded

An Intersection Entity Example A CD may be a part of many orders. An order may contain many CDs. The CD-order relationship is M:M. Where do you store quantity of CD’s on an order?

Adding Intersection Entities 1.Create an intersection entity (line item). 3. The “1” side goes on the original entities. 2.Move the “M’s” are adjacent to the intersection entity.

M:N to 1:Ms Rule: The M always go to the intersection entity. Why?

Creating An Entity- Relationship Diagram

Steps in Building Data Models 1.Review existing data models 2.Define entities a.Independent b.Dependent, including Intersection entities 3.Define attributes and keys (primary, foreign) 4.Define relationships 5.Finalize ERD 6.Normalize 7.Integrate data models as required 8.Verify completeness of the data model 9.Validate the data model a.With users b.With the enterprise’s data administrator

Design Guidelines Best practices rather than rigid rules Entities should have many instances (don’t include fixed items such as stationery headings) Avoid unnecessary attributes (outside the scope of your system) Apply correct cardinality and modality Labels reflect common business terms Assumptions should be clearly stated

Summary The ERD is the most common technique for drawing data models. The building blocks of the ERD are: –Entities (nouns), describe people, places, or things –Attributes (nouns), capture information about the entity –Relationships (active verb sentences) associate data across entities; they have cardinality and modality

End of Slides - Extra slides follow

Metaphors ER ModelRelational Model DatabaseSpreadsheet EntityRelationTable, FileTable InstanceTupleRecordRow Attribute FieldColumn IdentifierKey

Identifiers An identifier should have the following characteristics: –Its value should not change over the life of each instance –Its value should never be “null” or empty –It should be composed of the minimal number (preferably one) of attributes required to ensure uniqueness

Some Ways to Depict Relationships Entity 1Entity 2 Entity 1Entity 2 Entity 1Entity 2 1:1 1:M 1:0 or M

Data Modeling To identify entity types, look for nouns in the requirements Customers will access the Internet sales system to look for CDs of interest. Some customers will search for specific CDs or CDs by specific artists, whereas other customers want to browse for interesting CDs in certain categories (e.g., rock, jazz, classical). When the customer has found all the CDs he or she wants, the customer will check out by providing personal information regarding the order (e.g., the CDs to purchase and quantity for each item). The system will verify the customer’s credit card information with an on-line credit card clearance center and either accept the order or reject it. - Dennis & Wixom, p.159