IDEF1X Standard IDEF1X (Integrated Definition 1, Extended) was announced as a national standard in 1993 It defines entities, relationships, and attributes.

Slides:



Advertisements
Similar presentations
Information System Analysis Lab 7. ERD entity-relationship diagram is a data modeling technique that creates a graphical representation of the entities,
Advertisements

Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques
Data Modeling and the Entity-Relationship Model
Data Modeling and the Entity-Relationship Model
Database Processing: Fundamentals, Design, and Implementation, 9/e by David M. KroenkeChapter 5/1 Copyright © 2004 Please……. No Food Or Drink in the class.
IT420: Database Management and Organization
Data Modeling and the Entity-Relationship Model
Data Modeling and the Entity-Relationship Model
© 2002 by Prentice Hall 1 David M. Kroenke Database Processing Eighth Edition Chapter 3 The Entity- Relationship Model.
Concepts of Database Management Sixth Edition
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1 COS 346 Day 6.
Entity-Relation Modeling Hun Myoung Park, Ph.D., Public Management and Policy Analysis Program Graduate School of International Relations International.
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.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1 David M. Kroenke Database Processing Tenth Edition Chapter 5 Data.
McGraw-Hill/Irwin Copyright © 2007 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter 5 Understanding Entity Relationship Diagrams.
Chapter Five Data Modeling with the Entity-Relationship Model.
© 2002 by Prentice Hall 1 David M. Kroenke Database Processing Eighth Edition Chapter 3 The Entity- Relationship Model.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1 COS 346 Day 6.
Fundamentals, Design, and Implementation, 9/e COS 346 Day 2.
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.
Data Modeling and the Entity-Relationship Model Chapter Four DAVID M. KROENKE and DAVID J. AUER DATABASE CONCEPTS, 5 th Edition.
Chapter Five Data Modeling with the Entity-Relationship Model.
Entity-Relationship (E-R) Model
Data Modeling and the Entity-Relationship Model Chapter Four DAVID M. KROENKE’S DATABASE CONCEPTS, 2 nd Edition.
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.
3 Chapter 3 Entity Relationship (E-R) Modeling Database Systems: Design, Implementation, and Management, Fifth Edition, Rob and Coronel.
Chapter 5 Entity–Relationship Modeling
Entity Relationship Diagrams Objectives s Learn the Elements of the E-R model (entities, attributes, and relationships) s Show how to apply the E-R model.
1 ER Modeling BUAD/American University Entity Relationship (ER) Modeling.
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 2/1 Copyright © 2004 Please……. No Food Or Drink in the class.
1 5 Modeling Techniques A line manager states, “I know the Chinese say one picture is worth 1,000 words but these diagrams, there are so many that I’d.
DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall, modified by Dr. Lyn Mathis 5-1 David M. Kroenke’s, 10 th ed. Chapter.
Programming Logic and Design Fourth Edition, Comprehensive Chapter 15 System Modeling with the UML.
Data Modeling IST210 Class Lecture.
Component 4/Unit 6b Topic II Relational Databases Keys and relationships Data modeling Database acquisition Database Management System (DBMS) Database.
IDEF1X (Integrated Definition 1, Extended  IDEF1X narrows the definition of entities, attributes, and relationships  IDEF1X adds the notion of domains.
Entity Relationship Modeling
Chapter 4 Extended Entity-Relationship (EER)Model Incorporates Set-subset Relationships Incorporates Generalization Hierarchies Constraints: Coverage Constraints:
Entity Relationship Diagram (ERD). Objectives Define terms related to entity relationship modeling, including entity, entity instance, attribute, relationship.
Chapter 8 Entity-Relationship Modeling Pearson Education © 2009.
David M. Kroenke and David J. Auer Database Processing Fundamentals, Design, and Implementation Appendix C: E-R Diagrams and The IDEF1X Standard.
Database Design, Application Development, and Administration, 6 th Edition Copyright © 2015 by Michael V. Mannino. All rights reserved. Chapter 5 Understanding.
ENTITY RELATIONSHIP DIAGRAM. Objectives Define terms related to entity relationship modeling, including entity, entity instances, attribute, relationship.
Copyright © 2014 Pearson Canada Inc. 5-1 Copyright © 2014 Pearson Canada Inc. Application Extension 5a Database Design Part 2: Using Information Technology.
BBY 464 Semantic Information Management (Spring 2016) Data and Metadata Management Yaşar Tonta & Orçun Madran [yasartonta, Hacettepe.
ER Diagrams ● Many different notations are available ● From wikipedia:wikipedia: Entity-relationship modelwikipedia: Entity-relationship model ● How do.
Application Extension 5a
Data Modeling and the Entity-Relationship Model
Chapter 5 Database Design
© Shamkant B. Navathe CC.
Business System Development
Entity Relationship (E-R) Modeling
Requirements Become the E-R Data Model
COS 346 Day 8.
Object Oriented Analysis and Design
Software Engineering Lecture #11.
© Shamkant B. Navathe CC.
Module 8 – Database Design Using the E-R Model
Entity-Relation Modeling
Data Modeling and the Entity-Relationship Model
© Shamkant B. Navathe CC.
Chapter 1: The Database Environment
Database Processing: David M. Kroenke’s Chapter Five:
© Shamkant B. Navathe CC.
Enhanced Entity-Relationship (EER) Modeling
Entity Relationship (ER) Modeling
Data Modeling and the Entity-Relationship Model
© 2008 Pearson Prentice Hall, Experiencing MIS, David Kroenke
Presentation transcript:

IDEF1X Standard IDEF1X (Integrated Definition 1, Extended) was announced as a national standard in 1993 It defines entities, relationships, and attributes in more specific meanings It changed some of the E-R graphical symbols It includes definition of domains, a component not present in the extended E-R model Four Relationship Types Non-Identifying Connection Relationships Identifying Connection Relationships Non-Specific Relationships Categorization Relationships Products supporting IDEF1X: ERWin, Visio, Design/2000 Copyright © 2004

Example: IDEF1X Copyright © 2004

Example: IDEF1X Copyright © 2004

Example: IDEF1X Copyright © 2004

Non-Identifying Connection Relationships Represent relationship with a dashed line from a parent to a child entity Default cardinality is 1:N with a mandatory parent and an optional child 1 indicates exactly one child is required Z indicates zero or one children Copyright © 2004

Non-Identifying Connection Relationships Copyright © 2004

Identifying Connection Relationships Same as ID-dependent relationships in the extended E-R model Parent’s identifier is always part of the child’s identifier Relationship are indicated with solid lines, child entities are shown with rounded corners (ID-dependent entities only) Copyright © 2004

Identifying Connection Relationships Copyright © 2004

Non-Specific Relationships Simply a many-to-many relationship Relationships are shown with a filled-in circle on each end of the solid relationship line Cannot set minimum cardinalities of a non-specific relationship Copyright © 2004

Non-Specific Relationships Copyright © 2004

Categorization Relationships A relationship between a generic entity and another entity called a category entity Called specialization of generalization/subtype relationships (IS-A relationships) in the extended E-R model Within category clusters, category entities are mutually exclusive Two types of category clusters: Complete: every possible type of category for the cluster is shown (denoted by two horizontal lines with a gap in-between) Incomplete: at least one category is missing (denoted by placing the category cluster circle on top of a single line, no gap between horizontal lines) Copyright © 2004

Example: Categorization Relationships Copyright © 2004

Example: IDEF1X Model With Relationship Names Normally, a name consists of a verb or verb phrase expressed from the standpoint of the parent in the relationship, followed by a slash, and followed by the verb phrase expressed from the standpoint of the child. Copyright © 2004

Example: IDEF1X Model With Relationship Names Normally, a name consists of a verb or verb phrase expressed from the standpoint of the parent in the relationship, followed by a slash, and followed by the verb phrase expressed from the standpoint of the child. Copyright © 2004

Domains A domain is a named set of values that an attribute can have It can be a specific list of values or a pre-defined data characteristic, e.g. character string of length less than 75 Domains reduce ambiguity in data modeling and are practically useful Two types of domains Base domain: have a data type and possibly a value list or range definition Type domain: a subset of a base domain or a subset of another type domain Copyright © 2004

Example: Domain Hierarchy Copyright © 2004

UML-style E-R Diagrams The Unified Modeling Language (UML) is a set of structures and techniques for modeling and designing object-oriented programs (OOP) and applications The concept of UML entities, relationships, and attributes are very similar to those of the extended E-R model Several OOP constructs are added: <Persistent> indicates that the entity class exist in the database UML allows entity class attributes UML supports visibility of attributes and methods UML entities specify constraints and methods in the third segment of the entity classes Currently, the object-oriented notation is of limited practical value Copyright © 2004

Example: UML Each entity is represented by an entity class, which is shown as a rectangle with three segments. The top segment shows the name of the entity and other data that we will discuss. The second segment lists the names of the attributes in the entity, and the third documents constraints and lists methods (program procedures) that belong to the entity. Relationships are shown with a line between two entities. Cardinalities are represented in the format x..y, where x is the minimum required and y is the maximum allowed. Copyright © 2004

Example: UML Each entity is represented by an entity class, which is shown as a rectangle with three segments. The top segment shows the name of the entity and other data that we will discuss. The second segment lists the names of the attributes in the entity, and the third documents constraints and lists methods (program procedures) that belong to the entity. Relationships are shown with a line between two entities. Cardinalities are represented in the format x..y, where x is the minimum required and y is the maximum allowed. Copyright © 2004

Example: UML Each entity is represented by an entity class, which is shown as a rectangle with three segments. The top segment shows the name of the entity and other data that we will discuss. The second segment lists the names of the attributes in the entity, and the third documents constraints and lists methods (program procedures) that belong to the entity. Relationships are shown with a line between two entities. Cardinalities are represented in the format x..y, where x is the minimum required and y is the maximum allowed. Copyright © 2004

UML: Weak Entities A filled-in diamond is placed on the line to the parent of the weak entity (the entity on which the weak entity depends). Figure 2-28(a) shows a weak entity that is not an ID-dependent entity. It is denoted by the expression <non-identifying> on the PATIENT-PRESCRIPTION relationship. Figure 2-28(b) shows a weak entity that is ID-dependent. It is denoted with the label <identifying>. Copyright © 2004

UML: Subtypes A filled-in diamond is placed on the line to the parent of the weak entity (the entity on which the weak entity depends). Figure 2-28(a) shows a weak entity that is not an ID-dependent entity. It is denoted by the expression <non-identifying> on the PATIENT-PRESCRIPTION relationship. Figure 2-28(b) shows a weak entity that is ID-dependent. It is denoted with the label <identifying>. Copyright © 2004

Chapter 2 Entity-Relationship Data Modeling: Tools and Techniques