Bite sized training sessions: Data Modelling – Part 1 of 2 Data Model Diagrams Feb 2011 Prepared by Guy Beauchamp Group Projects & IT.

Slides:



Advertisements
Similar presentations
Chapter # 4 BIS Database Systems
Advertisements

Entity-Relationship (ER) Modeling
© Copyright 2011 John Wiley & Sons, Inc.
BUSINESS DRIVEN TECHNOLOGY Plug-In T4 Designing Database Applications.
Alternative Approach to Systems Analysis Structured analysis
Copyright Irwin/McGraw-Hill Data Modeling Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Accounting System Design
Modeling the Data: Conceptual and Logical Data Modeling
FIS 431/631 Financial Information Systems: Analysis and Design REA Modeling Joe Callaghan Oakland University Department of Accounting & Finance.
ISMT221 Information Systems Analysis and Design Entity-Relationship Diagram Lab 4 Tony Tam.
Entity-Relationship Model and Diagrams (continued)
1 The Accounting REA Model as an Information Engineering Interaction Model Slides 5.
Database Design Chapter 2. Goal of all Information Systems  To add value –Reduce costs –Increase sales or revenue –Provide a competitive advantage.
FIS 431/631 Financial Information Systems: Analysis and Design ERD & Normalization Joe Callaghan Oakland University Department of Accounting & Finance.
CS424 PK, FK, FD Normalization Primary and Foreign Keys Primary and foreign keys are the most basic components on which relational theory is based. Primary.
Database – Part 2a Dr. V.T. Raja Oregon State University.
Systems Analysis I Data Flow Diagrams
Bite sized training sessions: Process Modelling – Part 1 of 2 Process Model Diagrams.
Transforming Data Models into Database Designs
Michael F. Price College of Business Chapter 6: Logical database design and the relational 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.
Mapping ERM to relational database
Trisha Cummings.  Most people involved in application development follow some kind of methodology.  A methodology is a prescribed set of processes through.
Practical tips for creating entity relationship diagrams (ERDs) Chitu Okoli Associate Professor in Business Technology Management John Molson School of.
Class Agenda – 04/04/2006 Discuss database modeling issues
Modeling Systems Requirements: Events and Things.
Computer System Analysis Chapter 10 Structuring System Requirements: Conceptual Data Modeling Dr. Sana’a Wafa Al-Sayegh 1 st quadmaster University of Palestine.
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.
PowerPoint Presentation for Dennis, Wixom, & Roth Systems Analysis and Design, 3rd Edition Copyright 2006 © John Wiley & Sons, Inc. All rights reserved..
Database Design Using the REA Data Model
COMM 226 Practical tips for creating entity relationship diagrams (ERDs) Chitu Okoli Associate Professor in Business Technology Management John Molson.
Learningcomputer.com SQL Server 2008 – Entity Relationships in a Database.
CSCI 3140 Module 2 – Conceptual Database Design Theodore Chiasson Dalhousie University.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
Normalization (Codd, 1972) Practical Information For Real World Database Design.
Bite sized training sessions: Data Modelling – Part 2 of 2 Data Definitions.
Database Design Principles – Lecture 3
Introduction to Databases Trisha Cummings. What is a database? A database is a tool for collecting and organizing information. Databases can store information.
Implementing an REA Model in a Relational Database
Domain Modeling Part1: Entity Relationship Diagram Chapter 4 pp part 1 1.
1.  An introduction to data modelling  The purpose of data modelling  Modelling data relationships 2.
IS 475/675 - Introduction to Database Design
Database Design – Lecture 3 Conceptual Database Design.
1 IRU – database design part one Geoff Leese September 2009.
IMS 4212: Introduction to Data Modeling—Relationships 1 Dr. Lawrence West, Management Dept., University of Central Florida Relationships—Topics.
Description and exemplification of entity-relationship modelling.
Btec National - Advanced Databases 1 Advanced Databases Entity Relationship Diagrams.
Database Design – Lecture 4 Conceptual Data Modeling.
Database Design – Lecture 6 Moving to a Logical Model.
INTRODUCTION TO DATABASE DESIGN. Definitions Database Models: Conceptual, Logical, Physical Conceptual: “big picture” overview of data and relationships.
PowerPoint Presentation for Dennis & Haley Wixom, Systems Analysis and Design, 2 nd Edition Copyright 2003 © John Wiley & Sons, Inc. All rights reserved.
Link tables and keys Access/IPS Walsall College of Arts & Technology.
Entity Relationship Diagram (ERD). Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship.
Btec National - IT SYSTEMS ANALYSIS AND DESIGN 1 IT Systems Analysis and Design Entity Relationship Diagrams.
EntityRelationshipDiagrams. Entity Relationship Models The E-R (entity-relationship) data model views the real world as a set of basic objects (entities)
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 10 Structuring.
McGraw-Hill/Irwin Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 6 Modeling the Data: Conceptual and Logical Data Modeling.
ENTITY RELATIONSHIP DIAGRAM. Objectives Define terms related to entity relationship modeling, including entity, entity instances, attribute, relationship.
Let try to identify the conectivity of these entity relationship
Systems Analysis and Design
Process Modeling Graphically represent the processes that capture, manipulate, store, and distribute data between a system and its environment Models DFDs.
Database Requirements and Design
Database Design – Lecture 4
Entity-Relationship Model and Diagrams (continued)
Entity relationship diagrams
IST 318 Database Administration
Guide to Modeling Keys to E-R diagrams.
Guide to Modeling Keys to E-R diagrams.
Relationships—Topics
Presentation transcript:

Bite sized training sessions: Data Modelling – Part 1 of 2 Data Model Diagrams Feb 2011 Prepared by Guy Beauchamp Group Projects & IT

Objectives To understand –What is a data model … and what it is not! –Why do data modelling To be able to –Read a data model –Build a data model –Critically review a data model

What is a data model? Specification of the data that is required in order for –The solution to meet it’s objectives –Processes to be able to run A data model comprises: –A diagram showing the required data dependencies –A set of data definitions required for each attribute on the diagram Also referred to as: –Logical Data Model (LDM) –Entity Model –Entity Relationship Diagram (ERD) –Data Dictionary –Object Model –Class Diagram –Data Structure –…etc!

What a data model is not A physical design for storing data A database design Database table definitions Object specification

Why do data modelling? Data & Process Requirements Databas e Designs Physical data Specs System Specs Manual Procedures Designed As Designed As Designed As Designed As Manipulate Solution Specification

Data Model Components EntityA real world thing or an interaction between 2 or more real world things. RelationshipHow and why entities depend on each other (the relationship) and what that relationship is (the cardinality of the relationship). AttributeThe atomic pieces of information that we need to know about entities.

Entity A real world thing –E.g. Customer, Product An event between 2 or more entities –E.g. Sale “A real world thing or an interaction between 2 or more real world things.”

‘Type’ Entities Categorises other entities Holds information that applies to sets of other entities Very common Typical relationship cardinality is mandatory 1:M Relationship names add little value

Relationships There are dependency business rules between two entities – can be shown as: “How entities depend on each other in terms of why the entities depend on each other (the relationship) and what that relationship is (the cardinality of the relationship).” NB: there are other notations.

Relationship Names Always name relationships in at least one direction (except for those involving Type entities) Especially useful when there is more than one relationship between two entities:

Reading relationships One Customer (entity) may (cardinality) purchase (relationship name) one or more (cardinality) SALEs (entity) One SALE must be purchased by one CUSTOMER Tip – start with the word “One”, never “MANY”

Attributes No (attribute)Name (attribute) 10Fred Bloggs(instance) 67Freda Jones(instance) Customer (entity) Customer NoProduct NoDate /2/ /2/2020 Sale NoNamePrice 101Flange£ Blitwort£34.50 Product “The atomic pieces of information that we need to know about entities”

Primary Keys A special kind of attribute, set of attributes and/or relationships Is the way for the business to identify 1 unique instance of an entity Certain rules apply to a primary key: Must not be repeated within an entity Once assigned can never be updated (only deleted) Must be the way that the business uniquely identify an instance of an entity Which attribute makes the best primary key? Why? No (attribute)Name (attribute) 10Fred Bloggs(instance) 67Freda Jones(instance) Customer (entity)

Purchased Purchased via Discussion: What is the PK of Sale? Do PKs need to be shown at the ‘FK’ end of a relationship? No (attribute)Name (attribute) 10Fred Bloggs(instance) 67Freda Jones(instance) Customer (entity) Customer NoProduct NoDate /2/ /2/2020 Sale NoNamePrice 101Flange£ Blitwort£34.50 Product Primary Keys are the navigation method for relationships

5 Data Modelling “No-No”s 1.No repeating attributes on entities E.g. On a Customer entity “1 st child name”, “2 nd child name”… 2.No attributes on entities that do not depend on the primary key E.g. On Customer entity “order date” 3.No “Many to Many”s between entities E.g. Product ordered by many customers, a customer orders many products 4.No “one to one”s between entities (usually) E.g. Customer has one Membership Card and a Membership Card is for one Customer 5.No circular relationships between entities (usually) E.g. next slide

Circular relationships

How do we fix this circular relationship?

Process for producing a data model diagram identify candidate entities select a central candidate entity define the primary key work through the rest of the candidate entities consider whether it is in scope define the primary key define the relationship(s) between the candidate entity and all other candidate entities on the diagram create description entities as needed fully express the cardinality of the relationship(s) name the relationship(s) as needed validate everything with the user review and refine.

Next step: Data definitions… … covered in part 2 of this bite sized training session

Minor Exercise I own a florist’s shop called My Florist. I want to start ing reminders to customers when special occasions are due for which they have brought flowers in the past – for example a spouse’s birthday. Let’s draw up a data model to support that process.

An answer…

Major Exercise You are business analysts working for a company called re-Evolution Coffee Houses Ltd You have been given a piece of work – ref handouts Produce a data model showing –Entities –Primary Keys –Relationships Suggestion: follow the process for producing a data model diagram 4 slides previously The business users will be available for questions

If you need to make an assumption about business requirements or anything else then document it Time allowed: 1 hour Deliverable: –Flip chart data model –Flip chart assumptions Be prepared to present your data model to the other team Don’t worry about completing the exercise Do worry about the quality of what you get through Major Exercise

…and finally Any questions? Further resources… Feedback Thank-you!