Database Processing Fundamentals Design and Implementation Fifteenth Edition

Database Processing: Fundamentals, Design, and Implementation Fifteenth Edition Appendix C E-R Diagrams and the ID EF 1 X and UML Standards Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Learning Objectives C. 1 To understand IDEF 1 X-standard E-R diagrams. C. 2 To be able to model nonidentifying connection relationships, nonspecific relationships, and categorization relationships using the IDEF 1 X E-R model. C. 3 To understand the differences between E-R generalization/subtype relationships and IDEF 1 X categorization relationships. C. 4 To understand the use of domains in the IDEF 1 X E-R model. C. 5 To understand UML-style E-R diagrams. C. 6 To be able to model HAS-A, nonidentifying, and IS-A relationships using UML symbols. C. 7 To understand the object-oriented programming language constructs used in UML. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

IDEF 1 X • IDEF 1 X is an acronym for Integrated Definition 1, Extended. • IDEF 1 X is a variation of the entity-relationship (E-R) model discussed in Chapter Five. • IDEF 1 X was announced as a national standard in 1993. • IDEF 1 X assumes that a relational database will be used. • Being a government standard, most data modeling products support IDEF 1 X. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-1 Correspondence of Terms between the Extended E-R Model and the IDEF 1 X Version Extended E-R model Term Corresponding IDEF 1 X E-R Version Term Remarks Entity Same. Attribute Same. Relationship Same. 1: 1 and 1: N relationships Nonidentifying connection relationship Connection relationship is the same as HAS-A relationship. N: M relationship Nonspecific relationship Blank ID-dependent relationship identifying connection relationship Blank Weak entity, but not ID dependent None Blank Supertype entity Generic entity has an IS-A relationship to a category cluster. Subtype entity Category entities are mutually exclusive in their category cluster. None Domain Blank Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-2 EDEF 1 X Relationship Terms • Nonidentifying Connection Relationships • Identifying Connection Relationships • Nonspecific Relationships • Categorization Relationships Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Nonidentifying Connection Relationships (1 of 2) • 1: 1 or 1: N relationships between non-ID-dependent entities • Same as HAS-A relationships Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Nonidentifying Connection Relationships (2 of 2) • Default cardinality is 1: N, M-O. – This is shown by a dashed line with a filled-in circle by the child. – P (Positive = one or more) by the circle shows a required child. – (Diamond) next to parent indicates an optional parent. • 1: 1 is notated with a 1 next to the filled in circle. • Z indicates 0 or 1 children are allowed. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-3 Nonidentifying Connection Relationships Copyright © 2019, 2016, 2014 Pearson Education, Inc. All

Identifying Connection Relationship • Same as ID-dependent relationships. • The identifier of the parent is always part of the identifier of the child. • Default cardinality is 1: N, M-O. – This is shown by a solid line with a filled-in circle by the child. – P (Positive) indicates one or more. – 1 indicates one. – Z indicates zero or one. • The corners of the ID-dependent entity are rounded. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-4 Identifying Connection Relationship Copyright © 2019, 2016, 2014 Pearson Education, Inc. All

Nonspecific Relationships • Same as many-to-many (N: M) relationships. • Default cardinality is N: M, O-O. – This is shown by a solid line with a filled-in circle by both the parent and the child. – There is no way to indicate minimum cardinalities for this relationship. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-5 Nonspecific Relationships Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights

Categorization Relationships • Same as supertype/subtype relationships. • A generic entity is a supertype. • A category entity is a subtype. • Category are grouped into category clusters. – There may be a discriminator. – Two types: ▪ Complete—every possible category is shown (two lines) ▪ Incomplete—not all possible categories are shown (one line) • Default cardinality is 1: 1, M-O. – This is shown by a solid line. – Minimum cardinality of 1 on the parent is not shown. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-6 Categorization Relationships Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights

Domains • A domain is a named set of values that an attribute can have: – May be general (Character. String(max 50)) – May be specific ({Red, Blue, Green}) – May be a range (1000 -1999) • Domains reduce ambiguity. • Domains are useful. • Domain types: – Base Domain—a domain having a data type and possibly a value list or range definition – Type Domain—a subset of a base domain or another type domain Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-7 Incomplete and Complete Category Clusters Copyright © 2019, 2016, 2014 Pearson Education,

Figure C-8 Examples of Domain Hierarchy Copyright © 2019, 2016, 2014 Pearson Education, Inc.

Unified Modeling Language (UML) • Unified Modeling Language (UML) is Used to create E-R diagrams Important because of its association with object-oriented programing and the Object Management Group. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

UML Representation of Strong Entities • UML Representation of Strong Entities: – Represents 1: 1, 1: N, and N: M HAS-A relationships – Each entity is represented by an entity class ▪ Top segment shows the name of the entity ▪ Second segment lists the names of the attributes in the entity ▪ Third segment documents constraints and lists methods that belong to the entity – Relationships are shown with a solid line between entities – Cardinalities are shown as x. . y ▪ x is the minimum required ▪ y is the maximum allowed ▪ * means an unlimited number Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-9 UML Representation of Strong Entities Copyright © 2019, 2016, 2014 Pearson Education,

UML Representation of Weak Entities • UML Representation of Weak Entities: – A filled-in diamond is placed on the line to the parent of the weak entity (the child). – All weak entities have a parent, so the cardinality on the parent entity is always shown as 1. – ID-dependent weak entity relationships are denoted as <identifying>. – Non-ID-dependent weak entity relationships are denoted as <non-identifying>. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-10 UML Representation of Weak Entities Copyright © 2019, 2016, 2014 Pearson Education,

UML Representation of Subtypes • UML Representation of Subtypes: – Represents IS-A relationships – Current version of UML does not provide a means to document exclusivity but notation can be added to a UML diagram. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-11 UML Representation of IS-A Relationships Copyright © 2019, 2016, 2014 Pearson Education,

UML OOP Constructs (1 of 2) • The classes of all entities that are to be stored in the database are labeled – Data should continue to exist even if the OOP object that processes it is destroyed, or in other words: – The entity class is to be stored in the database. • UML entity classes can have class attributes. – Attributes of the class, not of entity instances – Cannot be stored in relational model databases ▪ Can be computed at run time ▪ Can be stored in a new entity Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

UML OOP Constructs (2 of 2) • Notation for visibility of attributes and methods – + (plus sign) —indicates attribute is public ▪ Is accessible and changeable by any method of any object – # (number sign) —indicates attribute is protected ▪ Is accessible only to methods of this class or its subclasses – − (minus sign) —indicates attribute is private ▪ Is accessible only to methods of this class • UML third segment holds constraints and methods – Constraints such as Primary. Key – Methods such as Get. Name() and Set. Name() Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved

Figure C-12 UML Representative of HAS-A Relationships Copyright © 2019, 2016, 2014 Pearson Education,

Copyright This work is protected by United States copyright laws and is provided solely for the use of instructors in teaching their courses and assessing student learning. Dissemination or sale of any part of this work (including on the World Wide Web) will destroy the integrity of the work and is not permitted. The work and materials from it should never be made available to students except by instructors using the accompanying text in their classes. All recipients of this work are expected to abide by these restrictions and to honor the intended pedagogical purposes and the needs of other instructors who rely on these materials. Copyright © 2019, 2016, 2014 Pearson Education, Inc. All Rights Reserved