Architecting and designing > Data modeling > Components of an entity relation diagram
  
Components of an entity relation diagram
The entity relation model
Represented by the entity relation or IDEF1X diagram
The logical Entity Relation diagram (ERD) and the logical IDEF1X diagram include two modeling objects: entities and relation lines.
An entity represents a person, place, event, or concept about which information will be maintained in the system
A relation line represents the associations between the entities.
System Architect displays entity symbols based on the nature of the relationship between two entities.
This graphic is described in the surrounding text.
Four types of relation lines are supported by System Architect:
Identifying relationship
In an identifying relation the existence of the child entity is completely dependent on the existence of its parent entity. The primary key of the parent entity is part of the primary key of the child entity. The identifying relation is, by definition, mandatory, and the parent cannot be specified as optional.
This graphic is described in the surrounding text.
Nonidentifying relationship
In a nonidentifying relation the child entity does not rely on the parent entity for its identification. The parent entity can be specified as mandatory or optional. The foreign keys propagated through a non-identifying relation line are not primary key attributes in the child entity.
This graphic is described in the surrounding text.
Non-specific relationship
A non-specific relation can indicate a many-to-many relation or an unknown relation. Foreign keys are not propagated through a non-specific relation. During the early stages of modeling a system, one might want to use non-specific relations in order to avoid getting locked into definitions.
A many-to-many relationship cannot be implemented in most relational databases and is, therefore, often resolved using an associative entity. When System Architect transforms an entity relation diagram into a physical data model, you can choose the resolution method to apply to many-to-many relationships.
This graphic is described in the surrounding text.
Super-Sub (ER Diagram) or Categorization (IDEF1X) Relationships
Both ER diagramming and IDEF1X support the notion of super-sub (categorization) relationships.
A super-sub or categorization relation indicates that a generic entity type (the supertype) is subdivided into subtypes. The supertype specifies the common attributes and relations that are shared by all subtypes. Each subtype specifies the attributes or relations which are distinct from other subtypes. The super-sub relation is, by nature, a parent/child identifying relationship; the subentities are always identified by the primary key of the supertype. The subtype cannot have primary key components which do not exist in the supertype.
The foreign keys which are propagated through a super-sub relation line in the entity relation model are always classified as primary key components in the subentity.
Nomenclature
 
ERD
IDEF1X
parent entity
super
generic
child entity
sub
category
relationship
super-sub
category cluster
Entity Relation
IDEF1X
Super-Sub Relation
This graphic is described in the surrounding text.
Category Cluster
Category clusters are divided into “complete” and “incomplete.”
In a complete category cluster all the possible categories are present. For example, a customer can be female or male.
This graphic is described in the surrounding text.
In an incomplete category cluster some categories are omitted. For example, the company has customers from many countries, but only those from the US and UK are modeled.
This graphic is described in the surrounding text.
See also
Metamodel of logical data modeling in System Architect
Entity relation models and datatypes
Creating project models and associated diagrams
Enabling the data modeling graphical consistency feature
Objects in an ERD
Data normalization
Creating an ERD from a PDM
Data modeling