Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







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

  1. Lists of repeating data items

  2. Lists of groups of repeating data items

Pointer extensions to data types

  1. Single pointers to other rows

  2. Lists of pointers to other rows

  3. Lists of pointers to pointers to other rows

  4. A pointer to another whole table

  5. 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.




Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.