ETEC 4601 – Database Systems

Chapter 5 – Data Modeling with the Entity-Relationship Model

© Copyright 2004 J. B. Gallaher

The Purpose of a Data Model

A data model is a plan, or blueprint, for a database design.

The Entity-Relationship Model

First published by Peter Chen in 1976Subtypes were added to the E-R model to create the extended E-R Model.

EntitiesAn entity is something that the users want to track.Readily identifiableEntities of a given type are grouped into an entity class

Attributes

Attributes describe the characteristics of entities.The E-R model assumes that all instances of an entity have the same attributes.

Identifiers

Identifiers are attributes that name, or identify, entity instances.Composite identifiers – consist of two or more attributes.Identifiers serve the same role for entities that keys serve for tables.

Relationships

Entities are associated with one another in relationships.Relationship classes are associations among entity classesRelationship instances are associations among entity instances.The number of entity classes in the relationship is the degree of the relationship.

Relationships (contiued)

Binary Relationships – relationships of degree two.Ternary relationships – relationships of degree three

Maximum CardinalityMaximum Cardinality is shown inside the diamond.Three basic maximum cardinalities:

One-to-oneOne-to-manyMany-to-many

Sometimes refered to as “Has-A” relationship.

Minimum CardinalityMinimum cardinality is the number of entity instances that must participate in a relationship.If the minimum is 0 then participation in the relationship is optionalIf the minimum is 1 then at least one entity instance must participate

Variations of the E-R ModelInformation Engineering uses crow's feet to show the many side of a relationshipIDEF1X (Integrated Definition 1, Extended) – a national standard uses different symbols as the E-R modelUnified Modeling Language (UML) adopted the E-R model but uses its own symbols and object oriented model.

ID-Dependent EntitiesAn ID-Dependent entity is an entity whose identifier includes the identifier of another entityID_dependent entities cannot exist unless the parent also exists.Minimum cardinality from the ID-dependent entity to the parent is always 1.

Weak EntitiesA weak entity is defined as any entity whose existence depends on the presence of another entity.A strong entity is any entity that is not weak.All ID-dependent entities are weakBut not all weak entities are ID-dependent.

Subtype Entities

Subtype entities are special cases of supertype entities.An attribute that determines which subtype is appropriate is called a discriminator.Subtypes can be:

Inclusive – the supertype can relate to one or more subtypesExclusive – the supertype relates to at most one subtype

Subtype Entities (continued)

Patterns in Forms, Reports, and Entity-Relationship Models

Forms and reports provide a good way to create a data model.Studying forms and reports can determine the entities and relationships that underlie it.Forms and reports can also be used to validate the data model.Many forms and reports fall into common patternsCommon patterns:

Strong Entity PatternsID-Dependent RelationshipsMixed Identifying and Nonidentifying PatternsFor-Use-By PatternsRecursive Patterns

Strong Entity Patterns1:1 Strong Entity Relationships

Strong Entity Patterns1:N Strong Entity Relationships

Strong Entity PatternsN:M Strong Entity Relationships

ID-Dependent Relationships

Three principle patterns use ID-dependent entities:

Multivalued attributeVersion/InstanceAssociation

ID-Dependent RelationshipsThe Association Pattern

Similar to the N:M strong relationshipThe association object contains additional information not contained in either of the strong entities.Association objects can connect more than two tables.

Note that Price does not exist in either of the entities.

Assignment associates 3 tables and adds HoursWorked.

ID-Dependent Relationships

The Multivalued Attribute PatternMany entities have characteristics that are multivalued.

ID-Dependent RelationshipsThe Archetype/Instance Pattern

The archetype/instance pattern occurs when one entity represents a manifestation of another entity.

Archetype

Instance

Mixed Identifying and Nonidentifying Patterns

Some pattern involve both identifying and nonidentifying relationships.The classic example is the line-item pattern

The For-Use-By PatternSome forms suggest the possibility of inappropriate nulls when they show blocks of data fields that are grayed out and labeled “For use by someone/something Only”

Recursive Patterns

1:1 Recursive RelationshipsIn a train, each boxcar has another boxcar on each end except the first and last boxcar.

Recursive Patterns

1:N Recursive Relationshipse.g. Employees have managers who manage many employees.

Recursive Patterns

N:M Recursive RelationshipsBills of Materials represent N:M recursive relationships.