Peter Chen invented entity/relationship modeling in the mid-1970ís [Chen 1977], and his approach remains widely used today. It is unique in its representation of relationships and attributes. Relationships are shown with a separate diamond-shaped symbol on the relationship line, and attributes are shown in separate circles, instead of annotations on each entity.
A sample model, representing Chenís method, is shown in Figure 1. This same example will be used to demonstrate all the techniques that follow. The model shows entities, attributes, and relationships. It also has examples of both a super-type/sub-type combination and a constraints between relationships.
In the diagram, each purchase order is related to a single party, and is related to one or more examples of either one product or one service.
The diagram also includes two entities (event and event category) in an unusual relationship. In most "one-to-many" relationships, the "one" side is mandatory ("... must be exactly one"), while the "many" side is optional ("... may be one or more"). In this example, the reverse is true: Each event may be in one and only one event category (zero or one), and each event category must be a classification for one or more events (one or more). That is, events may exist without being classified, or they may be in one and only one category. An event category can come into existence, however, only if there is at least one event to put into it.
Entities and attributes
Entities are represented by square-cornered boxes, with their attributes hanging off of them in circles. An entityís name appears inside the rectangle, and an attributeís name appears inside the circle. There are no special marks to indicate whether attributes are mandatory or optional, or if they participate in the entityís unique identifier.
Names of entities and attributes are common terms, and in multi-word names, the words are separated by hyphens.
Mr. Chenís notation is unique among the techniques shown here in that a relationship is shown as a two-dimensional symbol ó a rhombus on the line between two or more entities.
Note that this relationship symbol makes it possible to maintain a "many-to-many" relationship without necessarily converting it into an associative or intersect entity. In effect, the relationship itself is playing the role of an associative entity. The relationship itself is permitted to have attributes. Note how "quantity", "actual price", and "line number" are attributes of the relationship Order-line in Figure 1.
Note also that relationships do not have to be binary. As many entities as necessary may be linked to a relationship rhombus.
In Mr. Chenís original work, only one number appeared at each end, showing the maximum cardinality. That is, a relationship might be "one to many", with a "1" at one end and a "n" at the other. This would not indicate whether or not an occurrence of an entity had to have at least one occurrence of the other entity.
In most cases, an occurrence of an entity that is related to one occurrence of another must be related to one, and an occurrence of an entity that is related to more than one may be related to none, so most of the time the lower bounds can be assumed. The event/event category model, however, is unusual. Having just a "1" next to event showing that an event is related to one event category would not show that it might be related to none. The "n" which shows that each event category is related to more than one event would not show that it must be related to at least one.
For this reason, the technique can be extended to use two numbers at each end to show the minimum and maximum cardinalities. For example, the relationship party-order between purchase order and party, shows 1,1 at the purchase order end, showing that each purchase order must be with no less than one party and no more than one party. At the other end, "0,n" shows that a party may or may not be involved with any purchase orders, and could be involved with several. The event/event category model would have "0,1" at the event end, and "1,n" at the event category end.
In an alternative notation, relationship names may be replaced with "E" if the existence of occurrences of the second entity requires the existence of a related occurrence of the first entity.
Because relationships are clearly considered objects in their own right, their names tend to be nouns.
The relationship between purchase-order and person or organization, for example, is called order-line. Sometimes a relationship name is simply a concatenation of the two entity names. For example party-order relates party and purchase order.
Entity and relationship names may be abbreviated.
A unique identifier is any combination of attributes and relationships that uniquely identify an occurrence of an entity.
While Mr. Chen recognizes the importance of attributes as entity unique identifiers [Chen 1977, 23], his notation makes no provision for showing this. If the unique identifier of an entity includes a relationship to a second entity, he replaces the relationship name with "E", makes the line into the dependent entity an arrow, and draws a second box around this dependent entity. (Figure 2 shows how this would look if the relationship to party were part of the unique identifier of purchas-order). This still does not identify any attributes that are part of the identifier.
A sub-type is a subset of the occurrences of another entity, its super-type. That is, an occurrence of a sub-type entity is also an occurrence of that entityís super-type. An occurrence of the super-type is also an occurrence of exactly one or another of the sub-types.
Though not in Mr. Chenís original work, this extension is described By Robert Brown  and Mat Flavin .
In this extension, sub-types are represented by separate entity boxes, each removed from its super-type and connected to it by an "isa" relationship. (Each occurrence of a sub-type "is a[n]" occurrence of the super-type.) The relationship lines are linked by a rhombus and each relationship to a sub-type has a bar drawn across it. In Figure 1, for example, party is a super-type, with person and organization as its sub-types. Thus an order-line must be either a product or a service. This isnít strictly correct, since an order line is the fact that a product or a service was ordered on a purchase-order. It is not the same thing as the product or service themselves.
Constraints between relationships
The most common case of constraints between relationships is the "exclusive or", meaning that each occurrence of the base entity must (or may) be related to occurrences of one other entity, but not more than one. These will be seen in most of the techniques which follow below.
Mr. Chen does not deal with constraints directly at all. This must be done by defining an artificial entity and making the constrained entities into sub-types of that entity. This is shown in Figure 1 with the entity catalogue item, with its mutually exclusive sub-types product and service. Each purchase order has an order-line relationship with one catalogue item, where each catalogue item must be either a product or a service.
Mr. Chen was first, so it is not surprising that his technique does not express all the nuances that have been included in subsequent techniques. It does not annotate characteristics of attributes, and it does not show the identification of entities without sacrificing the names of the relationships.
While it does permit showing multiple inheritance and multiple type hierarchies, the multi-box approach to sub-types takes up a lot of room on the drawing, limiting the number of other entities that can be placed on it. It also requires a great deal of space to give a separate symbol to each attribute and each relationship. Moreover, it does not clearly convey the fact that an occurrence of a sub-type is an occurrence of a super-type.