Transforming Data Models into Database Designs

Slides:



Advertisements
Similar presentations
Designing tables from a data model (Chapter 6) One base table for each entity.
Advertisements

The Relational Model and Relational Algebra Nothing is so practical as a good theory Kurt Lewin, 1945.
Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. KroenkeChapter 5/1 Copyright © 2004 Please……. No Food Or Drink in the class.
Fundamentals, Design, and Implementation, 9/e COS 346 Day 8.
Systems Development Life Cycle
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1 COS 346 Day 9.
Fundamentals, Design, and Implementation, 9/e Chapter 5 Database Design.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-1 David M. Kroenke Database Processing Chapter 6 Transforming Data.
Chapter 3. 2 Chapter 3 - Objectives Terminology of relational model. Terminology of relational model. How tables are used to represent data. How tables.
Prentice Hall © COS 346 Day Agenda Questions? Assignment 7 Corrected –4 A’s and 4 B’s Assignment 8 posted –Due April 6 Quiz 2 next class.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-1 COS 346 Day 10.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-1 COS 346 Day 8.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-1 COS 346 Day 7.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 8-1 COS 346 Day 17.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-1 David M. Kroenke’s Chapter Six: Transforming Data Models into Database.
Fundamentals, Design, and Implementation, 9/e Chapter 7 Using SQL in Applications.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-1 David M. Kroenke’s Chapter Six: Transforming ER Models into Database.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-1 David M. Kroenke’s Chapter Six: Transforming ER Models into Database.
Slide 1 Chapter 05 – Part 1 Data Modeling with the Entity-Relationship Model.
APPENDIX C DESIGNING DATABASES
Michael F. Price College of Business Chapter 6: Logical database design and the relational model.
Chapter 14 & 15 Conceptual & Logical Database Design Methodology
Entity-Relationship Design
Database Design.  Define a table for each entity  Give the table the same name as the entity  Make the primary key the same as the identifier of the.
Chapter 4 The Relational Model.
Chapter 3 The Relational Model Transparencies Last Updated: Pebruari 2011 By M. Arief
IS 325 Notes for Wednesday September 18, 2013.
An Investigation of Oracle and SQL Server with respect to Integrity, and SQL Language standards Presented by: Paul Tarwireyi Supervisor: John Ebden Date:
Chapter Six Professor Adams’ Slides. Note that entities are shadowed, tables are not. Note that entities have no physical existence (blueprint) Note.
Chapter 9 Designing Databases Modern Systems Analysis and Design Sixth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Lecture 7 Integrity & Veracity UFCE8K-15-M: Data Management.
David M. Kroenke and David J. Auer Database Processing: F undamentals, Design, and Implementation Chapter Six: Transforming Data Models into Database Designs.
Database Design and Management CPTG /23/2015Chapter 12 of 38 Functions of a Database Store data Store data School: student records, class schedules,
Slide Chapter 5 The Relational Data Model and Relational Database Constraints.
Chapter 9: Logical Database Design and the Relational Model (ERD Mapping)
1 © Prentice Hall, 2002 Chapter 5: Logical Database Design and the Relational Model Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B.
Data Driven Designs 99% of enterprise applications operate on database data or at least interface databases. Most common DBMS are Microsoft SQL Server,
Database Design Sections 11 Database relationship, Integrity, keys, mapping conceptual model to logical/physical model Previous Section 12 – DDLesson11Fa12.ppt.
Constraints cis 407 Types of Constraints & Naming Key Constraints Unique Constraints Check Constraints Default Constraints Misc Rules and Defaults Triggers.
Information Access Mgt09/12/971 Entity-Relationship Design Information Level Design.
Gegevens Analyse Les 5: van ERD naar DSD.
1 ER Modeling BUAD/American University Mapping ER modeling to Relationships.
The Relational Model. 2 Relational Model Terminology u A relation is a table with columns and rows. –Only applies to logical structure of the database,
Session 1 Module 1: Introduction to Data Integrity
Slide 1 Chapter 05 – Part 2 Data Modeling with the Entity-Relationship Model.
© 2009 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 5 (Part a): Logical Database Design and the Relational Model Modern Database Management.
Chapter 3: Relational Databases
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 6-1 David M. Kroenke’s Chapter Six: Transforming Data Models into Database.
Databases Introduction - concepts. Concepts of Relational Databases.
David M. Kroenke and David J. Auer Database Processing Fundamentals, Design, and Implementation Chapter Six: Transforming Data Models into Database Designs.
LECTURE TWO Introduction to Databases: Data models Relational database concepts Introduction to DDL & DML.
Lecture # 14 Chapter # 5 The Relational Data Model and Relational Database Constraints Database Systems.
Chapter Six: Transforming Data Models into Database Designs 6-1.
Logical Database Design and the Rational Model
Chapter 5 Database Design
Chapter 4: Logical Database Design and the Relational Model
Transforming Data Models
CSIS 115 Database Design and Applications for Business
Quiz Questions Q.1 An entity set that does not have sufficient attributes to form a primary key is a (A) strong entity set. (B) weak entity set. (C) simple.
CSIS 115 Database Design and Applications for Business
COS 346 Day 8.
Transforming Data Models into Database Designs
Database Processing: David M. Kroenke’s Chapter Six:
CHAPTER 4: LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL
Entities Things about which you need to store data. One entity for each different thing. At least two attributes At least two occurrences Not a property.
Guide to Modeling Keys to E-R diagrams.
Database Processing: David M. Kroenke’s Chapter Six:
Database Processing: David M. Kroenke’s Chapter Six:
Guide to Modeling Keys to E-R diagrams.
Entity-Relationship Design
Presentation transcript:

Transforming Data Models into Database Designs Chapter 6 – Part 1 Transforming Data Models into Database Designs

Contents A. Computer Company Problem B. Solution

A. Computer Company Problem ProgLtd is a company that places computer programmers at temporary jobs. They keep track on each programmer: the programmer's identification number, the programmer's last name, the programmer's first name, the programmer's rank (Junior, Senior ...), gender, his/her hourly rate and what languages the programmer knows. Beside, each programmer has been issued a badge which is used for enter their office. On each badge has following information: badge’s code, the programmer's identification number, issued date.

ProgLtd deals with clients who may require programmers who know a particular programming language and may request programmers who are experienced in such a programming. Once a programmer is assigned a temporary job, ProgLtd would like to keep track of when he/she started the job, the total number of hours he/she is expected to spend at job and the date he/she finished the job. That is in addition to the client name and phone number where the temp has been assigned. Let’s design DB diagram for above requirements

B. Solutions Logical Analysis Physical Analysis

1. Logical Analysis

2. Physical Analysis 2.1. Steps for Transforming a Data Model into a Database Design. 2.2. Create Table for Each Entity. 2.3. Create Relationships. 2.4. Design for Minimum Cardinality. 2.5. Physical Diagram.

2.1. Steps for Transforming a Data Model into a Database Design.

2.2. Create Table for Each Entity 2.2.1. Create a Table for Each Entity. 2.2.2. Select the Primary Key. 2.2.3. Specify Candidate (Alternate) Keys. 2.2.4. Specify Column Properties.

2.2.1. Create a Table for Each Entity

2.2.2. Select the Primary Key The ideal primary key is short, numeric and fixed Surrogate keys meet the ideal, but have no meaning to users

2.2.3. Specify Candidate (Alternate) Keys The terms candidate key and alternate key are synonymous Candidate keys are alternate identifiers of unique rows in a table ERwin uses AKn.m notation, where n is the number of the alternate key, and m is the column number in that alternate key

2.2.4. Specify Column Properties 2.2.4.1. Specify Data Type. 2.2.4.2. Specify Default Value. 2.2.4.3. Specify Data Constraints.

2.2.4.1. Specify Data Type 2.2.4.1.1. SQL Server Data Types. 2.2.4.1.2. Data Types on Table.

2.2.4.1.1. SQL Server Data Types

2.2.4.1.2. Data Types on Table

2.2.4.2. Specify Default Value A default value is the value supplied by the DBMS when a new row is created Example: Default value of PRO_Hourly_Rate is 15$

2.2.4.3. Specify Data Constraints Data constraints are limitations on data values: Domain constraint - Column values must be in a given set of specific values Range constraint - Column values must be within a given range of values Intrarelation constraint – Column values are limited by comparison to values in other columns in the same table Interrelation constraint - Column values are limited by comparison to values in other columns in other tables [Referential integrity constraints on foreign keys]

2.3. Create Relationships 2.3.1. 1:1 Entity Relationships 2.3.2. 1:N Entity Relationships 2.3.3. N:M Entity Relationships

2.3.1. 1:1 Entity Relationships Place the key of one entity in the other entity as a foreign key: Either design will work – no parent, no child Minimum cardinality considerations may be important: O-M will require a different design that M-O, and one design will be very preferable.

2.3.2. 1:N Entity Relationships Place the primary key of the table on the one side of the relationship into the table on the many side of the relationship as the foreign key The one side is the parent table and the many side is the child table, so “Place the key of the parent in the child”

2.3.3. N:M Entity Relationships In an N:M strong entity relationship there is no place for the foreign key in either table The solution is to create an intersection table that stores data about the corresponding rows from each entity The intersection table consists only of the primary keys of each table which form a composite primary key Each table’s primary key becomes a foreign key linking back to that table

2.4. Design for Minimum Cardinality 2.4.1. Types of minimum cardinality. 2.4.2. Cascading Updates and Deletes. 2.4.3. Actions to Apply to Enforce Minimum Cardinality. 2.4.4. Implementing Actions.

2.4.1. Types of minimum cardinality Relationships can have the following types of minimum cardinality: O-O : Parent optional and child optional M-O : Parent mandatory and child optional O-M : Parent optional and child mandatory M-M : Parent mandatory and child mandatory We will use the term action to mean a minimum cardinality enforcement action. No action needs to be taken for O-O relationships.

2.4.2. Cascading Updates and Deletes A cascading update occurs when a change to the parent’s primary key is applied to the child’s foreign key. Surrogate keys never change and there is no need for cascading updates when using them. A cascading delete occurs when associated child rows are deleted along with the deletion of a parent row. For strong entities, generally do not cascade deletes. For weak entities, generally do cascade deletes.

2.4.3. Actions to Apply to Enforce Minimum Cardinality

2.4.4. Implementing Actions 2.4.4.1. Implementing Actions for M-O Relationships. 2.4.4.2. Implementing Actions for O-M Relationships. 2.4.4.3. Implementing Actions for M-M Relationships. 2.4.4.4. What is trigger?

2.4.4.1. Implementing Actions for M-O Relationships Make sure that: Every child has a parent. Operations never create orphans. The DBMS will enforce the action as long as: Referential integrity constraints are properly defined. The foreign key column is NOT NULL.

2.4.4.2. Implementing Actions for O-M Relationships The DBMS does not provide much help. Triggers or other application code will need to be written.

2.4.4.3. Implementing Actions for M-M Relationships The DBMS does not provide much help. Complicated and careful application programming will be needed.

2.4.4.4. What is trigger? Application programming uses SQL embedded in triggers, stored procedures, and other program code to accomplish specific tasks. A trigger is a stored program that is executed by the DBMS whenever a specified event occurs on a specified table or view. Triggers are used to enforce specific minimum cardinality enforcement actions not otherwise programmed into the DBMS.

2.5. Physical Diagram

?