1 Class Agenda (04/06/2006 and 04/11/2006)  Discuss use of Visio for ERDs  Learn concepts and ERD notation for data generalization  Introduce concepts.

Slides:



Advertisements
Similar presentations
Normalization Rules for Database Tables
Advertisements

BUSINESS DRIVEN TECHNOLOGY Plug-In T4 Designing Database Applications.
Chapter 3: The Enhanced E-R Model
© 2011 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 3: The Enhanced E-R Model Modern Database Management 10 th Edition Jeffrey A. Hoffer,
Chapter 3  Define terms  Understand use of supertype/subtype relationships  Understand use of specialization and generalization techniques  Specify.
1 Class Agenda (04/03 and 04/08)  Review and discuss HW #8 answers  Present normalization process Enhance conceptual knowledge of database design. Improve.
Modeling the Data: Conceptual and Logical Data Modeling
CHAPTER 3: THE ENHANCED E-R MODEL © 2013 Pearson Education, Inc. Publishing as Prentice Hall 1 Modern Database Management 11 th Edition Jeffrey A. Hoffer,
Chapter 4 © 2005 by Prentice Hall 1 Objectives Definition of terms Definition of terms Use of supertype/subtype relationships Use of supertype/subtype.
© 2005 by Prentice Hall Chapter 3a Database Design Modern Systems Analysis and Design Fourth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich.
Database Design Conceptual –identify important entities and relationships –determine attribute domains and candidate keys –draw the E-R diagram Logical.
The Relational Database Model:
Normalization I.
Chapter 5 Normalization Transparencies © Pearson Education Limited 1995, 2005.
Chapter 5 Normalization of Database Tables
IS 4420 Database Fundamentals Chapter 4: The Enhanced ER Model and Business Rules Leon Chen.
APPENDIX C DESIGNING DATABASES
Michael F. Price College of Business Chapter 6: Logical database design and the relational model.
Chapter 3: The Enhanced E-R Model
 Keys are special fields that serve two main purposes: ◦ Primary keys are unique identifiers of the relation in question. Examples include employee numbers,
Class Agenda – 04/04/2006 Discuss database modeling issues
Normalization Rules for Database Tables Northern Arizona University College of Business Administration.
Systems analysis and design, 6th edition Dennis, wixom, and roth
1 Class Agenda: 03/13 – 3/15  Review Database design – core concepts Review design for ERD Scenarios #3 & #4 Review concepts of normalization. Do practice.
Database Design Sections 4 & 5 Subtype, Supertype, Mutually exclusive, non-transferability, transferable, 1:1, 1:M, M:M, Redundant, Intersection entity,
1 Class Agenda (04/09 through 04/16)  Review HW #8  Present normalization process Enhance conceptual knowledge of database design. Improve practical.
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management Dave Salisbury ( )
1 Class Agenda (11/07 and 11/12)  Review HW #8 answers  Present normalization process Enhance conceptual knowledge of database design. Improve practical.
Functional Dependence An attribute A is functionally dependent on attribute(s) B if: given a value b for B there is one and only one corresponding value.
Concepts and Terminology Introduction to Database.
Normalization. 2 Objectives u Purpose of normalization. u Problems associated with redundant data. u Identification of various types of update anomalies.
Normalization A technique that organizes data attributes (or fields) such that they are grouped to form stable, flexible and adaptive entities.
The Relational Model and Normalization R. Nakatsu.
Normalization. Learners Support Publications 2 Objectives u The purpose of normalization. u The problems associated with redundant data.
Normalization (Codd, 1972) Practical Information For Real World Database Design.
Logical Database Design Relational Model. Logical Database Design Logical database design: process of transforming conceptual data model into a logical.
Normalization Transparencies
Copyright 2008 McGraw-Hill Ryerson 1 TECHNOLOGY PLUG-IN T5 DESIGNING DATABASE APPLICATIONS.
Data Models and Relational Databases Chapter 2. Learning Objectives Identify primary and foreign keys for each entity and relevant relationships in the.
Normalization Information Systems II Ioan Despi. Informal approach Building a database structure : A process of examining the data which is useful & necessary.
Normalization Well structured relations and anomalies Normalization First normal form (1NF) Functional dependence Partial functional dependency Second.
BIS 360 – Lecture Eight Ch. 12: Database Design and Normalization.
IS 475/675 - Introduction to Database Design
Chapter 10 Normalization Pearson Education © 2009.
Database Design – Lecture 8
1 The Enhanced Entity Relationship Diagrams (E-ERDs)
Chapter 16: Using Relational Databases Programming Logic and Design, Third Edition Comprehensive.
Chapter 3: The Enhanced E-R Model
Database Systems Supertypes and Subtypes Lecture # 10.
Database Management System Prepared by Dr. Ahmed El-Ragal Reviewed & Presented By Mr. Mahmoud Rafeek Alfarra College Of Science & Technology- Khan younis.
Creating Databases Data normalization. Integrity and Robustness. Work session. Homework: Prepare short presentation on enhancement projects. Continue working.
Normalization. 2 u Main objective in developing a logical data model for relational database systems is to create an accurate representation of the data,
Copyright © 2013 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill/Irwin APPENDIX C DESIGNING DATABASES APPENDIX C DESIGNING DATABASES.
Chapter 10 Designing Databases. Objectives:  Define key database design terms.  Explain the role of database design in the IS development process. 
Logical Database Design and the Relational Model.
© 2009 Pearson Education, Inc. Publishing as Prentice Hall 1 Chapter 4: The Enhanced E-R Model Modern Database Management 9 th Edition Jeffrey A. Hoffer,
Copyright © 2016 Pearson Education, Inc. Modern Database Management 12 th Edition Jeff Hoffer, Ramesh Venkataraman, Heikki Topi CHAPTER 3: THE ENHANCED.
Lecture 4: Logical Database Design and the Relational Model 1.
NormalisationNormalisation Normalization is the technique of organizing data elements into records. Normalization is the technique of organizing data elements.
Normalization ACSC 425 Database Management Systems.
Logical Database Design and Relational Data Model Muhammad Nasir
What Is Normalization  In relational database design, the process of organizing data to minimize redundancy  Usually involves dividing a database into.
Data Modeling Advanced Concepts Updated 20/4/2015 TMC2034 Database Concept and Design1.
The Enhanced E-R Model and Business Rules
LECTURE 4: Chapter 4: The Enhanced E-R Model
Example Question–Is this relation Well Structured? Student
Database Management System 1 (ITED123A)
Overview of Entity‐Relationship Model
CHAPTER 3: THE ENHANCED E-R MODEL
Chapter 5 Advanced Data Modeling
Presentation transcript:

1 Class Agenda (04/06/2006 and 04/11/2006)  Discuss use of Visio for ERDs  Learn concepts and ERD notation for data generalization  Introduce concepts of normalization

2 What is generalization?  Generalization is the concept that some entities share attributes.  Example: Imagine a university human resource system with an entity called “employee”. An employee has attributes such as name, address, SSN, birth date, educational level, etc. Different types of entities have other information.  For example, a “faculty” entity has grant type.  A “classified” entity stores data about employment level.  An “administrative” entity stores data about contract type.

4 Generalization vocabulary  An entity “supertype” is an entity whose instances have attributes that are common to one or more entity “subtypes”. Attributes that are shared by all entities (including the identifier) are associated with the supertype.  An entity “subtype” is an entity whose instances inherit some common attributes from an entity supertype. An entity “subtype” adds other attributes to those inherited from the supertype. A subgrouping of the entities in an entity type which has attributes that are distinct from those in other subgroupings.  Generalization allows an analyst to understand more fully the relationships between entities.

D

6 What are the generalization constraints?  Constraints are limitations depicted on a data model.  The most common types of constraints are: Completeness. Addresses the question of whether an instance of a supertype must also be a member of at least one subtype.  Result is either required or not required.  Specified on the ERD with the letter “C” under the arrow pointing to the supertype. Disjointness. Addresses the question of whether an instance of a supertype may simultaneously be a member of two or more subtypes.  Result is specified as disjoint or overlap.  Specified on the ERD with the letter “D” under the arrow pointing to the supertype.

7 Database Normalization  What will you know about database normalization? Define normalization. Know the vocabulary of normalization. Understand the process of normalization.  What will you be able to do? Be able to identify the characteristics of each normal form. Be able to tell whether or not a data model is in third normal form. Possibly be able to use normalization to assist you in the design of a database.

8 Review of database design goals  Protect the integrity of the data. Reduce data redundancy. Prevent data anomalies.  Provide for change. Prevent inflexible data structures. Anticipate changes.  Provide complete data for decision making.

9 What are data anomalies?  An anomaly is a potential error or inconsistency in the data.  Data anomalies are most frequently caused by the implementation of M:N relationships.  A M:N relationship can be implemented through a “false” 1:M relationship.

Example of a “False” 1:m Relationship Order net net net cod cod Product 5613 tumbler 12 oz ea inventory Sacramento South tumbler 12 oz ea inventory Sacramento North food processor ea inventory Sacramento North paper rm supplies Sacramento South glass pitcher ea inventory Reno

11 Potential anomalies in the example  Insertion anomaly: Can’t add “some” of a row; must have all the key attributes. Example - Suppose we need to add a new warehouse?  Deletion anomaly: Lose some relevant data when deleting other data. Example - What happens to the Reno warehouse information (name and phone#) when we delete item #4512?  Update anomaly: Must update more than one row when one piece of data changes. Examples - What happens if the telephone number at the Sacramento North warehouse changes? What happens if the date the purchase order was placed is entered incorrectly and must be updated?

12 Other problems with “false” 1:m relationships  What happens when the database design grows or changes?  How do you add new data attributes? What about keeping track of the buyer for an order? Or the manager for a warehouse?

13 What is normalization?  Normalization is a formal, process- oriented approach to data modeling.  Normalization is the process of: examining groups of data attributes; splitting them into appropriate entities; identifying the relationships between the entities; and identifying appropriate primary and foreign keys.

14 Normalization process  Some refer to this as the “bottom-up” form of database design.  Contrast with the more intuitive “top- down” approach we have been using.  The results from the normalization process are stable, flexible entities. The results from the intuitive approach should be the same.

15 Two methods of applying normalization 1. Use it to help in designing a database. Normalization starts with a single entity. Normalization breaks that entity into a series of additional entities. More entities are discovered and named during the process. Entities are linked during the process. 2. Use it to validate the design of a database. Identify entities from the meaning of the data. Create conceptual and logical data models. Apply the rules of normalization to ensure a stable, non-redundant design.

16 Vocabulary for normalization  A “functional dependency" is a relationship between attributes in which one attribute or group of attributes determines the value of another.  A “determinant” is an attribute that, once known, can determine the value of another attribute.

Examples of functional dependencies and determinants  A social security number determines your name and address. SSN  name, address.  A vehicle id number determines the make and model of a car. VIN  make, model.  Name and address are “functionally dependent” on SSN.  SSN “determines” name and address.  Functional dependency diagram format: CrsNum  CrsDescription, CrsCredits ZipCode  City, State PatID, TrtID, LocID, TrtDateTime  TstResults

18 Normalization process  Normalization is accomplished in stages. A “normal form” is a state (level of completeness) of a data model.  Unnormalized data: A data model that has not been normalized. It contains repeating groups and is not a stable model.  Unnormalized data is essentially one entity. The system under analysis is categorized as a single entity.

Semester Year Student Name Student Address Student City Student State Student Zip Code Student ID Student College Student Major Student Minor Student Year Course ID Course Title Course Instructor Course Credits Grade What attributes might be needed that aren’t visible on the grade report? Group all attributes in one “big” entity. Identify a primary key for the entity. Maybe studentID for this one. Unnormalized data for grade report exercise

20 First Normal Form  First normal form: Remove repeating groups. A repeating group is an attribute or group of attributes that can have more than one value for an instance of an entity. If it is a single attribute, we have been calling it a “multi-valued” attribute.  To get a data model into first normal form: Identify repeating groups and place them as separate entities in the model. Identify a primary key for the repeating group. The key may be concatenated. Create the relationships between entities. Divide m:n relationships with appropriate intersection entities.

21 Second Normal Form  Second normal form: Remove partial functional dependencies.  A partial functional dependency is a situation in which one or more non-key attributes are functionally dependent on part, but not all, of the primary key. Partial functional dependencies occur only with concatenated keys.  Examples of partial functional dependencies: PatID, TrtID, LocID, TrtDateTime  PatName, TstResults, TrtType, TrtDescription, LocName CourseID, StudentID  CourseTitle, Grade  Which entities developed in first normal form for the grade report have concatenated keys?

22 Third normal form  Third normal form: Remove transitive dependencies. A transitive dependency occurs when a non-key attribute is functionally dependent on one or more non-key attributes.  Third normal form examines entities with single primary keys and removes the “floating” or transitive dependencies.  It may be possible to have attributes that are determined by other attributes, rather than by the primary key. They must be removed into entities with appropriate primary keys.

23 Summary of normalization process  Examine and evaluate the logical data model for effectiveness. Find the repeating groups and put the model into first normal form. Identify primary key fields for any new entities. Relate entities with foreign keys. Find the functional dependencies. Identify the partial functional dependencies and put the model into second normal form. Identify primary key fields for any new entities. Relate entities with foreign keys. Find the transitive dependencies and put the model into third normal form. Identify primary key fields for any new entities. Relate entities with foreign keys.

24 Goal of normalization A set of entities where each attribute in each entity is dependent on the primary key, the whole primary key, and nothing but the primary key.