BIS3635 - Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong Chapter # 6 Advanced Data Modeling.

Slides:



Advertisements
Similar presentations
THE EXTENDED ENTITY RELATIONSHIP MODEL (EERM)
Advertisements

Relational Database Design Via ER Modelling
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.
Advanced Data Modeling
Entity Relationship (ER) Modeling
Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. KroenkeChapter 5/1 Copyright © 2004 Please……. No Food Or Drink in the class.
4 1 Chapter 4 Entity Relationship (ER) Modeling Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 6 Advanced Data Modeling.
Database Systems: Design, Implementation, and Management Tenth Edition Chapter 5 Advanced Data Modeling.
Database Systems: Design, Implementation, and Management Tenth Edition
Chapter 6 Advanced Data Modelling
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 6 Advanced Data Modeling.
Chapter 5 Understanding Entity Relationship Diagrams.
Entity Relationship (E-R) Modeling
Fundamentals, Design, and Implementation, 9/e COS 346 Day 8.
Fundamentals, Design, and Implementation, 9/e Chapter 5 Database Design.
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Understanding Entity Relationship Diagrams.
IS 4420 Database Fundamentals Chapter 4: The Enhanced ER Model and Business Rules Leon Chen.
Chapter 4 Entity Relationship (E-R) Modeling
Chapter 2: Entity-Relationship Model (Continued)
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,
Ch5: ER Diagrams - Part 2 Much of the material presented in these slides was developed by Dr. Ramon Lawrence at the University of Iowa.
3 Chapter 3 Entity Relationship (E-R) Modeling Database Systems: Design, Implementation, and Management, Fifth Edition, Rob and Coronel.
Database Systems: Design, Implementation, and Management Tenth Edition Chapter 5 Advanced Data Modeling.
MIS 385/MBA 664 Systems Implementation with DBMS/ Database Management Dave Salisbury ( )
4 1 Chapter 4 Entity Relationship (ER) Modeling Database Systems: Design, Implementation, and Management, Sixth Edition, Rob and Coronel.
Database Systems: Design, Implementation, and Management Tenth Edition
Database Systems: Design, Implementation, and Management Ninth Edition Chapter 6 Normalization of Database Tables.
BIS Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong Chapter # 5 Normalization of Database.
Chapter 8 Data Modeling Advanced Concepts Database Principles: Fundamentals of Design, Implementation, and Management Tenth Edition.
IS 475/675 - Introduction to Database Design
EXAMPLE. Subclasses and Superclasses Entity type may have sub-grouping that need to be represented explicitly. –Example: Employee may grouped into.
1 © Prentice Hall, 2002 Chapter 5: Logical Database Design and the Relational Model Modern Database Management 6 th Edition Jeffrey A. Hoffer, Mary B.
Chapter 2 : Entity-Relationship Model Entity Sets Relationship Sets Design Issues Mapping Constraints Keys E-R Diagram Extended E-R Features Design of.
1 The Enhanced Entity Relationship Diagrams (E-ERDs)
Entity Relationship Diagram (2)
UNIT_2 1 DATABASE MANAGEMENT SYSTEM[DBMS] [Unit: 2] Prepared By Lavlesh Pandit SPCE MCA, Visnagar.
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,
© 2011 Pearson Education 1 Chapter 3: Advanced Database Analysis Modern Database Management 10 th Edition, International Edition Jeffrey A. Hoffer, V.
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,
Entity Relationship Modeling
ICOM 5016 – Introduction to Database Systems Lecture 5 Dr. Manuel Rodriguez Department of Electrical and Computer Engineering University of Puerto Rico,
Computing & Information Sciences Kansas State University Friday, 26 Sep 2008CIS 560: Database System Concepts Lecture 13 of 42 Friday, 26 September 2008.
Database Systems: Design, Implementation, and Management Eighth Edition Chapter 6 Advanced Data Modeling.
Database Systems: Design, Implementation, and Management Ninth Edition
©Silberschatz, Korth and Sudarshan2.1Database System Concepts Chapter 2: Entity-Relationship Model Entity Sets Relationship Sets Mapping Constraints Keys.
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.
Ch 05. Basic Symbols ( manino ). Cardinalities Cardinality Notation.
Chapter 5 Understanding Entity Relationship Diagrams.
Database Design, Application Development, and Administration, 6 th Edition Copyright © 2015 by Michael V. Mannino. All rights reserved. Chapter 5 Understanding.
Data Modeling Advanced Concepts Updated 20/4/2015 TMC2034 Database Concept and Design1.
BTM 382 Database Management Chapter 5: Advanced Data Modeling
Lecture # 14 Chapter # 5 The Relational Data Model and Relational Database Constraints Database Systems.
Logical Database Design and the Rational Model
Chapter 5 Database Design
Chapter 4: Logical Database Design and the Relational Model
ER example : movie & category
Database Management System 1 (ITED123A)
Overview of Entity‐Relationship Model
CHAPTER 3: THE ENHANCED E-R MODEL
CHAPTER 4: LOGICAL DATABASE DESIGN AND THE RELATIONAL MODEL
Chapter 5 Advanced Data Modeling
Database Management system
Entity Relationship (ER) Modeling
Presentation transcript:

BIS Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong Chapter # 6 Advanced Data Modeling

In this chapter, you will learn: About the extended entity relationship (EER) model’s main constructs How entity clusters are used to represent multiple entities and relationships The characteristics of good primary keys and how to select them How to use flexible solutions for special data modeling cases What issues to check for when developing data models based on EER diagrams Objectives

Result of adding more semantic constructs to original entity relationship (ER) model Diagram using this model is called an EER diagram (EERD) The Extended Entity Relationship Model

Entity supertypes Generic entity type related to one or more entity subtypes Contains common characteristics Entity subtypes Contains unique characteristics of each entity subtype Entity Supertypes and Subtypes

Entity Supertypes and Subtypes (2)

Depicts arrangement of higher-level entity supertypes and lower-level entity subtypes Relationships described in terms of “IS-A” relationships Subtype exists only within context of supertype Every subtype has only one supertype to which it is directly related Can have many levels of supertype/ subtype relationships Specialization Hierarchy

Specialization Hierarchy (2)

Enables entity subtype to inherit attributes and relationships of supertype All entity subtypes inherit their primary key attribute from their supertype At implementation level, supertype and its subtype(s) maintain a 1:1 relationship Entity subtypes inherit all relationships in which supertype entity participates Lower-level subtypes inherit all attributes and relationships from all upper level-supertypes Inheritance …

Inheritance (2) …

Attribute in supertype entity Determines to which entity subtype each supertype occurrence is related Default comparison condition for subtype discriminator attribute is equality comparison Subtype discriminator may be based on other comparison condition Subtype Discriminator

Disjoint subtypes Also known as non-overlapping subtypes Subtypes that contain unique subset of supertype entity set Overlapping subtypes Subtypes that contain nonunique subsets of supertype entity set Disjoint and Overlapping Constraints

Disjoint and Overlapping Constraints (2)

Disjoint and Overlapping Constraints (3)

Specifies whether entity supertype occurrence must be a member of at least one subtype Partial completeness Symbolized by a circle over a single line Some supertype occurrences that are not members of any subtype Total completeness Symbolized by a circle over a double line Every supertype occurrence must be member of at least one subtype Completeness Constraint

Completeness Constraint (2)

Specialization Identifies more specific entity subtypes from higher-level entity supertype Top-down process Based on grouping unique characteristics and relationships of the subtypes Specialization and Generalization

Generalization Identifies more generic entity supertype from lower-level entity subtypes Bottom-up process Based on grouping common characteristics and relationships of the subtypes Specialization and Generalization (2)

Virtual entity type used to represent multiple entities and relationships in ERD Considered “virtual” or “abstract” because it is not actually an entity in final ERD Temporary entity used to represent multiple entities and relationships Eliminate undesirable consequences Avoid display of attributes when entity clusters are used Entity Clustering

Entity Clustering (2)

Primary key most important characteristic of an entity Single attribute or some combination of attributes Primary key’s function is to guarantee entity integrity Primary keys and foreign keys work together to implement relationships Properly selecting primary key has direct bearing on efficiency and effectiveness Entity Integrity: Selecting Primary Keys

Natural key is a real-world identifier used to uniquely identify real-world objects Familiar to end users and forms part of their day-to-day business vocabulary Generally data modeler uses natural identifier as primary key of entity being modeled May instead use composite primary key or surrogate key Natural Keys and Primary Keys

Attribute that uniquely identifies entity instances in an entity set Could also be combination of attributes Main function is to uniquely identify an entity instance or row within a table Guarantee entity integrity, not to “describe” the entity Primary keys and foreign keys implement relationships among entities Behind the scenes, hidden from user Primary Key Guidelines

Primary Key Guidelines (2)

Composite primary keys useful in two cases: As identifiers of composite entities Where each primary key combination allowed once in M:N relationship As identifiers of weak entities Where weak entity has a strong identifying relationship with the parent entity Automatically provides benefit of ensuring that there cannot be duplicate values When to Use Composite Primary Keys

When to Use Composite Primary Keys (2)

When used as identifiers of weak entities normally used to represent: Real-world object that is existent-dependent on another real-world object Real-world object that is represented in data model as two separate entities in strong identifying relationship Dependent entity exists only when it is related to parent entity When to Use Composite Primary Keys (3)

Especially helpful when there is: No natural key Selected candidate key has embedded semantic contents Selected candidate key is too long or cumbersome When to Use Surrogate Primary Keys

If you use surrogate key Ensure that candidate key of entity in question performs properly Use “unique index” and “not null” constraints When to Use Surrogate Primary Keys (2)

When to Use Surrogate Primary Keys (3)

Data modeling and design requires skills acquired through experience Experience acquired through practice Four special design cases that highlight: Importance of flexible design Proper identification of primary keys Placement of foreign keys Design Cases: Learning Flexible Database Design

Foreign keys work with primary keys to properly implement relationships in relational model Put primary key of the “one” side on the “many” side as foreign key Primary key: parent entity Foreign key: dependent entity Design Cases # 1: Implementing 1:1 Relationships

In 1:1 relationship two options: Place a foreign key in both entities (not recommended) Place a foreign key in one of the entities Primary key of one of the two entities appears as foreign key of other Design Cases # 1: Implementing 1:1 Relationships (2)

Design Cases # 1: Implementing 1:1 Relationships (3)

Design Cases # 1: Implementing 1:1 Relationships (4)

Normally, existing attribute values replaced with new value without regard to previous value Time-variant data: Values change over time Must keep a history of data changes Keeping history of time-variant data equivalent to having a multivalued attribute in your entity Must create new entity in 1:M relationships with original entity New entity contains new value, date of change Design Cases # 2: Maintaining History of Time-Variant Data

Design Cases # 2: Maintaining History of Time-Variant Data (2)

Design Cases # 2: Maintaining History of Time-Variant Data (3)

Design trap occurs when relationship is improperly or incompletely identified Represented in a way not consistent with the real world Most common design trap is known as fan trap Fan trap occurs when one entity is in two 1:M relationships to other entities Produces an association among other entities not expressed in the model Design Cases # 3: Fan Traps

Design Cases # 3: Fan Traps (2)

Design Cases # 3: Fan Traps (3)

Redundancy is seldom a good thing in database environment Occur when there are multiple relationship paths between related entities Main concern is that redundant relationships remain consistent across model Some designs use redundant relationships to simplify the design Design Cases # 4: Redundant Relationships

Design Cases # 4: Redundant Relationships (2)

Data modeling translates specific real-world environment into data model Represents real-world data, users, processes, interactions EERM enables the designer to add more semantic content to the model Data modeling checklist helps ensure data modeling tasks successfully performed Based on concepts and tools learned since Chapter 3 Data Modeling Checklist

Data Modeling Checklist (2)

THE END