Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida.

Slides:



Advertisements
Similar presentations
CHAPTER OBJECTIVE: NORMALIZATION THE SNOWFLAKE SCHEMA.
Advertisements

Chapter 10: Designing Databases
Post Exam Study Database Design
BUSINESS DRIVEN TECHNOLOGY Plug-In T4 Designing Database Applications.
Database Systems: Design, Implementation, and Management Tenth Edition
Chapters 7 & 9 System Scope
IT420: Database Management and Organization
Data Modeling is an Analysis Activity
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 6 Advanced Data Modeling.
Database Systems: Design, Implementation, and Management Tenth Edition
Concepts of Database Management Sixth Edition
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1 COS 346 Day 6.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1 David M. Kroenke Database Processing Tenth Edition Chapter 5 Data.
Entity Relationship Diagrams
Entity-Relationship Model and Diagrams (continued)
Chapter Five Data Modeling with the Entity-Relationship Model.
Modern Systems Analysis and Design Third Edition
Chapter 4 Relational Databases Copyright © 2012 Pearson Education, Inc. publishing as Prentice Hall 4-1.
Concepts of Database Management Seventh Edition
Mgt 20600: IT Management & Applications Databases Tuesday April 4, 2006.
Chapter 4 Relational Databases Copyright © 2012 Pearson Education 4-1.
APPENDIX C DESIGNING DATABASES
Michael F. Price College of Business Chapter 6: Logical database design and the relational model.
Chapter 5 UNDERSTANDING AND DESIGNING ACCOUNTING DATA.
IST Databases and DBMSs Todd S. Bacastow January 2005.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1 David M. Kroenke’s Chapter Five: Data Modeling with the Entity-Relationship.
ระบบฐานข้อมูลขั้นสูง (Advanced Database Systems) Lecturer AJ. Suwan Janin Phone:
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.
Chapter 4 The Relational Model.
DATABASE MANAGEMENT SYSTEMS BASIC CONCEPTS 1. What is a database? A database is a collection of data which can be used: alone, or alone, or combined /
DATABASE MANAGEMENT SYSTEMS BASIC CONCEPTS 1. What is a database? A database is a collection of data which can be used: alone, or alone, or combined /
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management Dave Salisbury ( )
Chapter 9 Designing Databases Modern Systems Analysis and Design Sixth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
© 2006 ITT Educational Services Inc. SE350 System Analysis for Software Engineers: Unit 8 Slide 1 Chapter 9 Structuring System Data Requirements.
1 ER Modeling BUAD/American University Entity Relationship (ER) Modeling.
Concepts and Terminology Introduction to Database.
Organizing Data and Information AD660 – Databases, Security, and Web Technologies Marcus Goncalves Spring 2013.
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 3/1 Copyright © 2004 Please……. No Food Or Drink in the class.
Component 4: Introduction to Information and Computer Science Unit 6: Databases and SQL Lecture 2 This material was developed by Oregon Health & Science.
An Introduction to Java Chapter 11 Object-Oriented Application Development: Part I.
R McFadyen Chapter 7 Conceptual Data Modeling.
Lecture 12 Designing Databases 12.1 COSC4406: Software Engineering.
I Information Systems Technology Ross Malaga 4 "Part I Understanding Information Systems Technology" Copyright © 2005 Prentice Hall, Inc. 4-1 DATABASE.
Chapter 8 Data Modeling Advanced Concepts Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition.
Lecture2: Database Environment Prepared by L. Nouf Almujally & Aisha AlArfaj 1 Ref. Chapter2 College of Computer and Information Sciences - Information.
1 Relational Databases and SQL. Learning Objectives Understand techniques to model complex accounting phenomena in an E-R diagram Develop E-R diagrams.
MIS 673: Database Analysis and Design u Objectives: u Know how to analyze an environment and draw its semantic data model u Understand data analysis and.
Concepts of Database Management Sixth Edition Chapter 6 Database Design 2: Design Method.
Lecture2: Database Environment Prepared by L. Nouf Almujally 1 Ref. Chapter2 Lecture2.
Unit 3 Conceptual Data Modeling. Key Concepts Conceptual data modeling process Classes and objects Attributes Identifiers, candidate keys, and primary.
DataBase Management System What is DBMS Purpose of DBMS Data Abstraction Data Definition Language Data Manipulation Language Data Models Data Keys Relationships.
Database Development Supertype, Subtype, and Business Rules Powered by DeSiaMore 1.
Copyright 2006 Prentice-Hall, Inc. Essentials of Systems Analysis and Design Third Edition Joseph S. Valacich Joey F. George Jeffrey A. Hoffer Chapter.
1 © Prentice Hall, 2002 Chapter 5: Logical Database Design and the Relational Model Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B.
Component 4/Unit 6b Topic II Relational Databases Keys and relationships Data modeling Database acquisition Database Management System (DBMS) Database.
Object-Oriented Modeling: Static Models. Object-Oriented Modeling Model the system as interacting objects Model the system as interacting objects Match.
1 DATABASE TECHNOLOGIES (Part 2) BUS Abdou Illia, Fall 2015 (September 9, 2015)
Chapter 10 Designing Databases. Objectives:  Define key database design terms.  Explain the role of database design in the IS development process. 
Fundamentals, Design, and Implementation, 9/e Appendix B The Semantic Object Model.
1 10 Systems Analysis and Design in a Changing World, 2 nd Edition, Satzinger, Jackson, & Burd Chapter 10 Designing Databases.
David M. Kroenke and David J. Auer Database Processing Fundamentals, Design, and Implementation Appendix H: The Semantic Object Model.
Database Design, Application Development, and Administration, 6 th Edition Copyright © 2015 by Michael V. Mannino. All rights reserved. Chapter 5 Understanding.
Logical Database Design and the Rational Model
Business System Development
Chapter 4: Logical Database Design and the Relational Model
Information Systems Today: Managing in the Digital World
Modern Systems Analysis and Design Third Edition
Chapter 9 Designing Databases
CHAPTER 4: LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL
Chapter 3: Modeling Data in the Organization
Presentation transcript:

Copyright © 2009 David C. Hay 1 Converting An Essential Entity/Relationship Model Into A Real Database Design Enterprise Data World David Hay Tampa, Florida April 6, 2009 David C. Hay Enterprise Data World Austin, Texas May 1, 2014 Essential Strategies International 13 Hilshire Grove Lane Houston, TX

Copyright © 2014 David C. Hay 2 Different points of view... Data modeler End User Designer

Copyright © 2014 David C. Hay 3 Data Modeler’s Assignment...  Capture the language of the business  Do so in as flexible and robust a manner as possible. Data modeler

Copyright © 2014 David C. Hay 4 How to achieve flexibility and robustness...  Generalize entity classes, Each describes as large a population of phenomena as possible. For example, a Party is a Person or an Organization that is of interest to the company. Organization in this case can then have more specific sub-types, like Company, Government Agency, Household, etc.  Separate roles from the definitions of things. For example, an “Employee” is a Person who is employed by an Organization, such as a company. A “Vendor” is a Party who is a vendor in an Order.

Copyright © 2014 David C. Hay 5 How to achieve flexibility and robustness...  Put as much of the language of the business as instances of...type entity classes. This includes categories, like Activity Type and Product Type.  Treat nearly all attributes as being multi- valued, requiring a separate entity class. For example, Party Characteristic, with an intersect entity class Party Characteristic Value each instance of which contains a “Value” of a Party Characteristic for a particular Party.  Essential Data Model – General concepts Super-set of user views

Copyright © 2014 David C. Hay The End User’s view...  The end user, on the other hand deals with very concrete, particular things.  The user interface must reflect the way the user deals with things today.  The behavior of the system is an extension of the user’s behavior.  Ideally ‘e participated in the modeling and agreed with the overall concepts.  But those abstractions have little to do with today’s problems. 6 End User

Copyright © 2014 David C. Hay 7 Designer’s Assignment...  Designers may not be experienced with models this abstract.  This paper is intended to present some of the more basic steps required to convert an essential data model into a database design.  It turns out that abstract models are implemented using the same steps as not so abstract models.

Copyright © 2014 David C. Hay 8 Connections to System Users...  Conceptual Data Model – General concepts Super-set of user views  User Views – Concrete terms Habits and personal preferences  Database and Application Design True to conceptual model Accommodates technological limits Makes user views possible

Copyright © 2014 David C. Hay UML Alert!  Both the Essential Data Model and the Relational Database Design shown here use constrained versions of the Unified Modeling Language.  Translation: 9 UML SymbolEssential Symbol Design Symbol ClassEntity TypeTable AssociationRelationshipForeign Key Attribute Column InheritanceSub-type(resolved)

Copyright © 2014 David C. Hay 10 Four Steps to Design 1.Resolve sub-types. 2.Perform default database design 3.Design computed columns. 4.De-normalize as necessary. 5.Deal with those parameters.

Copyright © 2014 David C. Hay 11 Four Steps to Design 1.Perform default database design 2.Resolve sub-types. 3.Design computed columns. 4.De-normalize as necessary. 5.Deal with those parameters

Copyright © 2014 David C. Hay 12 The Default Database Design...  Each entity class becomes a table.  Each attribute becomes a column.  Each primary identifier becomes a primary key. Each component of the identifier is a reference to a column in the table.  Each role on the “many” end of a relationship becomes a foreign key, composed of pointers to the columns in the other table’s primary key.  If a relationship from table A to table B was part of a unique identifier, the columns in table A that are the foreign key implementation of that relationship become part of the primary key for Table A.

Copyright © 2014 David C. Hay {id} 13 An Entity/Relationship Diagram... Identifier s

Copyright © 2014 David C. Hay 14 The Default Conversion... Primary Keys Foreign Key Columns Foreign Keys

Copyright © 2014 David C. Hay 15 Four Steps to Design 1.Perform default database design 2.Resolve sub-types. 3.Design computed columns. 4.De-normalize as necessary. 5.Deal with those parameters

Copyright © 2014 David C. Hay 16 Resolve sub-types  V1: One table for the super-type. All attributes from all sub-types become columns. Cannot meaningfully enforce mandatory columns. Requires adding “type” column.  V2: One table for each sub-type. Attributes for super-type plus sub-type form columns for each sub-type table. Foreign keys for each relationship linked to super- type in each sub-type table.  V3: Combinations Most complex. Most “true”.

Copyright © 2014 David C. Hay 17 For example, this model... Implement Sub-types Inherit super-type attributes Collapse un- implement ed sub- types

Copyright © 2014 David C. Hay 18 Could be implemented, thus... “Department number is only required if “Organization Type Name” is “Department”.

Copyright © 2014 David C. Hay Criteria  Relative frequency of sub-type retrieval?  Who is going to do it? Different populations? Different timings? 19

Copyright © 2014 David C. Hay 20 Four Steps to Design 1.Perform default database design 2.Resolve sub-types. 3.Design computed columns. 4.De-normalize as necessary. 5.Deal with those parameters

Copyright © 2014 David C. Hay 21 Design Computed Columns...  Compute on input: if values are relatively stable, or if retrieval volume per day is significantly greater than update volume. Maintenance is required to keep values consistent.  Compute on output: if values are relatively dynamic, or if retrieval volume is relatively low. Additional maintenance is unnecessary.  Kinds of calculations: Simple: A*B+C Inference: INFER-THRU (,, ) Summation: SUM-THRU (,, )

Copyright © 2014 David C. Hay 22 For example, this model... /Price INFER-THRU (to buy, Product Type, Unit Price) /Value = Quantity * Price /Contract Value = SUM-THRU (composed of, Line Item, Value) /Total Sales to Date = SUM-THRU (bought via, Line Item, Value)

Copyright © 2014 David C. Hay 23 Could be implemented thus... Computed on input (and stored) Computed on query* * Note that translating the formula into, for example, a stored procedure, is left to the viewer.

Copyright © 2014 David C. Hay 24 Four Steps to Design 1.Perform default database design 2.Resolve sub-types. 3.Design computed columns. 4.De-normalize as necessary. 5.Deal with those parameters

Copyright © 2014 David C. Hay 25 De-normalize (three methods)... 1.Inherit reference values. 2.Split tables horizontally (by instance). 3.Split tables vertically (by column).

Copyright © 2014 David C. Hay 26 Inherit from reference tables... buyer in seller in This model...

Copyright © 2014 David C. Hay 27 Could be implemented as... CONTRACTS CONTRACT_NUMBER(PK) ISSUE_DATE TOTAL_VALUE BUYER_NAME SELLER_NAME LINE_ITEM CONTRACT_NUMBER(FK) PRODUCT_NAME QUANTITY COST STANDARD_PRICE VALUE

Copyright © 2014 David C. Hay Note:  When replicating values, recognize the maintenance required to keep them consistent.  Note that the paradigm of INFER-THRU and SUM-THRU already anticipated this.  If these are implemented as dynamic columns, maintenance is automatic.  If they are implemented as static copies, maintenance must be added. 28 Have you heard this before? Denormalization replicates computed fields

Copyright © 2014 David C. Hay 29 Split Horizontally (instances)...  For example, By Geographic Area  Some tables for North American customers  Some tables for European customers  Etc. By Customer Type, etc.  Some tables for corporate customers  Some tables for individual customers  Etc.  Note the problems that will arise if a significant number of customers (for example) fall into more than one category.

Copyright © 2014 David C. Hay 30 Split Vertically (columns)...  For example, People with customer attributes  Annual sales  Sales representative  Etc. People with employee attributes  Social security number  Employment date  Note that people with both kinds of attributes would appear redundantly in both tables.

Copyright © 2014 David C. Hay 31 NOTE...  De-normalization optimizes some operations at the expense of others.  Test the effects before making them permanent.  Document the rationale for the de- normalization.

Copyright © 2014 David C. Hay 32 Four Steps to Design 1.Perform default database design 2.Resolve sub-types. 3.Design computed columns. 4.De-normalize as necessary. 5.Deal with those parameters.

Copyright © 2014 David C. Hay 33 About those parameters...  Some entity classes (Party, for example) invariably have a lot of attributes.  And they change over time.  Their definitions change over time.  We need an alternative.  Define attributes as data.  Also called: Characteristics, Parameters, Variables, Etc.  Here’s an approach for Party, for example

Copyright © 2014 David C. Hay 34 Party parameters as “Characteristics”... PARTY CHARACTERISTIC: “Height” “Number of employees” “Regulatory target”, Etc. PARTY CHARACTERISTIC VALUE: “Height” of “Jerry Smith” has CHARACTERISTIC VALUE of “6.1” (feet)… according to “Jerry Smith”.

Copyright © 2014 David C. Hay 35 Party Characteristic Constraints... NOTE: the CONTINUOUS PARTY CHARACTERISTIC “Height” -- may only be used as a PARTY CHARACTERISTIC VALUE -- for a PARTY that is an example of the PARTY TYPE “Person”.

Copyright © 2014 David C. Hay 36 Designing those parameters...  While it is a powerful way of dealing with the complexity of data …  …the Parameter Model makes common manipulations harder, however.  Convert parameters that are... Relatively stable Not multi-valued (Over time?)  Do not convert parameters that are... Multi-valued Changeable over time and this must be reported.

Copyright © 2014 David C. Hay 37 For example, in this model...

Copyright © 2014 David C. Hay 38  These Characteristics:  Could be implemented as: Can be implemented thus... PEOPLE BIRTHDATE HEIGHT PARTY CHARACTERISTIC NameDescription(Party Type) BirthdateThe day the person appearedPerson HeightVertical distance Person Annual SalesAverage sales in a yearCompany Tax ID IRS tax identifierCompany COMPANIES ANNUAL SALES TAX IDENTIFICATION NUMBER Bad idea!

Copyright © 2014 David C. Hay 39 Four Steps to Design 1.Perform default database design 2.Resolve sub-types. 3.Design computed columns. 4.De-normalize as necessary. 5.About those parameters. 6.About those user views.

Copyright © 2014 David C. Hay 40 In summary: About Those User Views...  The database designer need only balance data model integrity with performance issues.  The application designer must take the data as organized in a database and present it reasonably to each particular end user.  This requires skill in understanding both the database and the underlying data model.

Copyright © 2014 David C. Hay 41 Questions... ?