Home > Articles > Programming

This chapter is from the book

Using Entity/Relationship and Object Models

The definition of a data model says only that boxes represent things and lines represent relationship between pairs of things. The definition doesn't say anything about how a data model is to be used. In fact, the meaning of the boxes and lines can be very different in three of the Architecture rows we've been talking about.

Figure 3.1 shows the Architecture Framework with the Data column highlighted. Three perspectives have a particular interest in data or object models:

  • Business owners are interested in seeing representations of the tangible things of their business. They see things as being related to each other in complex ways. They view the data's external schema.

  • Architects are interested in the underlying structure of data. For them all relationships are binary and one-to-many. The principles of normalization have been applied. They are concerned with the conceptual schema.

  • Designers are interested in representations of the implications of data structure on the physical design of databases, whether they be relational, object oriented, or something else. They are interested in the logical schema that is appropriate to the technology they are using.

The graphic structure of data modeling is the same in all three rows, although, as described in Appendix B, different notations are better for the different views. Chen's notation is suitable for Row Two models, for example, since it can describe multi-way relationships. Oracle's notation works well for Row Three models, since it has minimal extra symbols for things not needed there. Object-role modeling can also be used for both Row Two and Row Three. In a relational environment, IDEF1X works well as a design technique, while object-oriented designers favor the UML. The following sections discuss this issue in more detail.

Business Owners' Views (Row Two)

The most important element of the business owners' views to capture is language. The first artifact to be created in any analysis project should be a glossary. This captures every technical, industry, and other specialized term and its definitions. If the same word is used in multiple ways, work with people to come up with a single definition, or, if that isn't possible, document the disagreement.

Once the terms have been captured, capture the facts of the enterprise. These are constructed from the terms in the glossary, and for the most part they can be represented in data models. However they are represented, the models prepared for business owners must be clear to them, in their language. In principle, any of the modeling notations could be used here, but since these models will be discussed with nontechnical people, it is desirable to use a technique whose aesthetic qualities make it attractive and easy to understand. In Row Two, the business owner's view, the entity types (classes), attributes, and relationships (associations) represent external schemata—business objects. The notation for such a model may allow multiway relationships, many-to-many relationships, and multivalued attributes. The important thing about this model is that it represents exactly the things the people in the business see. There is no diagrammatic rigor to the model, but it is important to use language precisely and clearly.

The business owners' models are also called divergent data models, because they constitute a diverse set of entity types.

An entity type could be a PURCHASE ORDER or a VENDOR, each of which is actually a combination of entity types and relationships. Multivalued attributes are permitted, such as the “line items” contained in a PURCHASE ORDER. Many of the relationships will be “many-to-many”, and relationships may be portrayed that are not binary. (A PROFESSOR teaches a COURSE in a CLASSROOM, for example.)

The aesthetics of the diagrams are important, since such people will have little patience for learning arcane diagraming conventions.

Architect's View (Row Three)

Models prepared for information architects (information system designers) are more disciplined. In Row Three, the architect attempts to identify underlying structures. At the syntactic level, all multiway relationships are transformed into sets of binary relationships. All many-to-many relationships between entity types are transformed into intersect entity types that represent occurrences of associations between the two entity types. All multi-valued attributes are converted into additional entity types, according to the rules of “normalization” (described below). Following these disciplines insures that the true natures of the data are really understood. In addition, at the semantic level, this model is expressed in terms of the most fundamental things of the business. What the business owners see may be but examples of these fundamental things. For example, business owners are usually conscious of VENDORS, CUSTOMERS, EMPLOYEES, and the like. In the architectural model, these are replaced with PERSON, and ORGANIZATION with a super-type called PARTY, where a PARTY is defined as either a person or an organization of interest to the enterprise. These are then related to each other, contracts, and other things, in order to show their roles as customers, vendors, employees, and so forth.

This means that entity types in architects' models may well be combinations of entity types in business owners' models. This is called a convergent data model, because the diverse entity types of the divergent models have been consolidated (“converged”) into a smaller number of more fundamental entity types.

Again, in principle, any of the modeling notations could be used for this kind of model, but, since these models also will be discussed with non-technical people, they should be as aesthetically clean and easy to understand as possible. Remember, it is the clients who ultimately must ensure that any assumptions made while creating either model were in fact true.

In addition to the simple resolution of anomalies in the context of a particular area, the architect also reaches out to other spheres of interest, to create a model that extends beyond the immediate environment. This means, for example, that what may appear to be a one-to-many relationship in the context of one department is really a many-to-many relationship when all departments are considered.

Designer's View (Row Four)

The set of boxes and lines that constitutes a data model's notation may also be used to represent the things in the designer's view. A designer sees a data model as an expression of computer artifacts. Specifically, what you see in Row Four depends on the technology you will be using: A relational designer sees tables, columns, and foreign keys; an object-oriented designer sees classes, attributes, and associations to be navigated. What is represented here are no longer things in the business but things in the computer.

Aesthetics are not as important to the designer as they are to the architect or the business owner. The designer likes to see more details in the diagram than do audiences of either of the other two kinds of models. Hence, these models may be more cluttered and complex.

It is here that the data model and the object model are used quite differently. The logical schema the designer uses depends on the database management system and development technology being used. If the implementation is to use relational technology, the boxes in the diagram represent tables, with variations on the technique representing foreign keys and other relational structures. IDEF1X is particularly suited for this.

Alternatively, the boxes can represent an object-oriented programmer's object classes, with additions to the notation for certain object-oriented constructs, such as composition and association navigation. The UML does this well.

Note, for example, that relational developers and object-oriented programmers view relationships quite differently in the design model. A relational database relates tables by associating matching columns. That is, a relationship represents a structure that is, by definition, mutual. If A is related to B, then by definition B is related to A.

In object-oriented programming, however, a relationship represents the two navigation paths from each class to the other. Where in a relational database a relationship simply asserts that two tables could be joined together in an SQL statement. In an object-oriented environment, a relationship means that program code implementing the behavior of each class will be used to implement one or both interactions between them.

Scott Ambler, for example, in a 1999 white paper, “Mapping Objects To Relational Databases” (http://www.ambysoft.com/mappingObjects.html), describes a model of ADDRESS and POSTAL AREA.5 In the world, and therefore in an analysis model, each ADDRESS must be in one POSTAL AREA, while each POSTAL AREA may be the location of one or more ADDRESSES, as shown in Figure 3.17.

03fig17.gifFigure 3.17. Analyst's ERD.

Note that the relationship's roles are named in both directions. The relationship from POSTAL AREA to ADDRESS is optional, since it is possible that a POSTAL AREA may have no addresses in it. For purposes of this exercise, we have stipulated that each ADDRESS must be in one POSTAL AREA, even though in the real world it may be the case that some addresses are specified without the POSTAL AREA, especially outside the United States.

This model, then, presupposes that any ZIP code specified for an ADDRESS will be validated by comparison with the ZIP codes for POSTAL AREAS in the reference entity type. It also envisions both a query as to the POSTAL AREA of an ADDRESS and of the ADDRESSES in a POSTAL AREA.

In Mr. Ambler's version of the model, however, there is not a “requirement” for the relationship to be documented in both directions. In his view, POSTAL AREA only exists to provide the behavior for validating a ZIP code attached to an ADDRESS. This validation, however, is limited to what can be inferred from a format and from the “City” the ADDRESS is in. It does not extend to examination of a master list of ZIP codes, and there certainly isn't any requirement to be able to go from a POSTAL AREA to the ADDRESSES in that POSTAL AREA. For these reasons, his model is much more constrained than the analysis entity/relationship diagram. Figure 3.18 shows the entity/relationship diagram of this design version of the problem. (The arrow is an annotation only. It is not an official part of the model.)

03fig18.gifFigure 3.18. OO Modeler's ER Model.

In Mr. Ambler's version, the model will only be navigated from ADDRESS to POSTAL AREA, so there is no need to specify the relationship from POSTAL AREA to ADDRESS. Since graphically there is no way not to specify the relationship in that direction, it is shown here as a “must be one and only one” relationship, without a meaningful name. Indeed, if the ZIP code is specified uniquely every time an ADDRESS is added, the relationship is in fact one-to-one, and it is mandatory. (Note that this means the same ZIP code can appear more than once in POSTAL AREA.)

In Mr. Ambler's example, the entity/relationship diagram in Figure 3.18 is not adequate to represent what is needed for design. UML is much more suited for this. Figure 3.19 shows the UML version of this model. Here we can see the arrow showing the only navigation direction. We can also see the names of the programs that implement each entity type's behavior. (OK, cardinality from POSTAL AREA to ADDRESS is shown, but your author doesn't know why.) The key program for this discussion is “validate” in POSTAL AREA. This is a program that will check the format of the code and check for consistency between the code and the state specified. (In the U.S. the first two digits of a ZIP code determine the state where the POSTAL AREA is located.)

03fig19.gifFigure 3.19. OO Modeler's UML Model.

This is clearly a design model. The notation has details (attribute formats, for example, and symbols qualifying attributes and behaviors) that are of interest to designers, but that are not of interest during analysis. It does not have relationship role names. In addition, as we have seen, its content differs from the original analysis model because of economic evaluations that were performed to constrain the design. The company cannot afford to buy a ZIP code master file (either from a financial or a logistical point of view), and it currently has no interest in locating addresses by ZIP code, so the design is modified to recognize that. Mr. Ambler says that this constrained approach is what is “required” by the business, but in fact it is only required because circumstances forced design to be something less than what is envisioned by the conceptual model. After all, applying economics to the conceptual model is what design is all about. The validation in this design is weaker than might be possible, but the company can decide to accept that. This is the sort of economic trade-off that designers do all the time.

Note, however, that circumstances may change in the future, and the ZIP code file may be deemed a good idea. The company may decide at that time that it wants to see all the addresses in a particular POSTAL AREA. Then it would be valuable to have constructed the conceptual model correctly, so you can see how the design model varied from it, and what now must be changed.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020