The Chen Entity Relationship Diagram Model

Oracle Database Tips by Donald Burleson

The Chen Diagram

The basic Chen diagram is the original entity relationship diagram that was developed by Peter Chen in 1976. The diagram is a graphical representation of entities and their relationships to each other. (Figure 3.7) An entity defines a person, place, thing, event or role that you want to keep data about. In the entity relationship diagram an entity is represented by a rectangle. A relationship is an association between two entities, a relationship is represented in the diagram by a diamond. The third part of the entity relationship diagram is called cardinality. Cardinality refers to the number of instances of one entity that can be related to an instance of another entity. Cardinality can be one to many (1, N), or many to many (M, N) or recursive many-to-many relationships.

In our sample diagram we see a one-to-many relationship between customer and order such that one customer may place many orders, but each order will belong to only one customer. We also see a many-to-many relationship between order and item, such that each order may contain many items, and each item may participate in many orders. Finally, we see a recursive many-to-many relationship, which is defined as an entity that has a many-to-many relationship with itself. For example, an item may have many sub items, which are items, while at the same time being a sub-component in a larger item For example, a carburetor has parts, while it is also a part of another item, the engine.

Figure 3.7 A Sample Chen Diagram

While the entity/relationship model is very good at describing the overall model for simple data relationships, it is not well suited for object database design. Object design requires that physical details be available to the modeler. When contrasted with relational database design, object/relational database design is far more complex. While the relational model dictates that all entities should be decomposed into their smallest components (third normal form), object databases allow far more flexibility in their design. This flexibility translates directly into more complexity for the system designer who must struggle with the huge amount of choices offered by these robust database engines.

Let's begin by exploring the additional structures that are introduced by object-oriented data models and then take a look at a practical diagramming method for object database systems.

Basic object data structures

In addition to collecting data types into user-defined data types, many of the object databases allow for the creation of extensions to the base table types. These extensions may be used to embed additional information into an object or they may be used to establish relationships to other objects. In addition the extensions may be used to create "aggregate" objects that consist entirely of data inside other objects.

These data type extensions fall into several categories:

Data extensions with user-defined data types

Lists of repeating data items
Lists of groups of repeating data items

Pointer extensions to data types

Single pointers to other rows
Lists of pointers to other rows
Lists of pointers to pointers to other rows
A pointer to another whole table
List of pointers to other whole tables

As we can see, we are presented with a mind-boggling array of choices of data structures. There are, however, certain rules that the database designer can follow when choosing a data structure to implement within their model. While each of these methods are fully discussed within Chapters 5 through Chapter 8, let's begin our journey by talking about how these data structures are represented graphically in our design documentation.

��