Entity-Relationship-Attribute Modeling

When we discussed the development of the entity and entity-relationship models as data frameworks we used the following definition of an entity.

An Entity is defined as a person, place, or thing which is a) of interest to the corporation, b) is capable of being described in real terms and c) is relevant within the context of the specific environment of the firm.

A more precise definition within the context of the framework model should have been

In a real world model each Entity represents a group or family of uniquely identifiable persons places, things, concepts (e.g. logical persons, places or things) or events of interest to the firm and about which the firm wants or must collect data or keep records. The data or records about each entity describe what they are, what they look like, how they are used, what purpose they serve, what actions they take or what actions are taken with or against them. Each entity in a real world model is uniquely differentiated from every other entity by a set of distinguishing characteristics.

For our discussion of entity-relationship-attribute models we must use a different definition

In a data model, each Entity is a data representation of a set of uniquely identifiable real world persons, places, things, concepts (e.g. logical persons, places or things) or events, that can be described in an identical or highly similar manner and which behave in an identical or highly similar manner. An entity is represented in the real world model only of it is of interest to the firm and is something the firm collects and maintains data about. Entities in the data model (or data entities) represent the actual data which must be collected and maintained.

The representation of the entity in the data model includes all of the characteristics and attributes of the entity, the actual data elements which must be present to fully describe each characteristic and attribute, and a representation of how that data must be grouped, organized and structured. Although the terms characteristics and attributes are sometimes be used interchangeably, attributes are the more general term, and characteristics are special use attributes.

The definitions of these three terms, attribute, characteristic and data element follow.

An Attribute:

An attribute must also be

1. of interest to the corporation
2. capable of being described in real terms, and
3. relevant within the context of the specific environment of the firm.

An attribute must be capable of being defined in terms of words or numbers. That is, the attribute must have one or more data elements associated with it. An attribute of an entity might be its name or its relationship to another entity. It may describe what the entity looks like, where it is located, how old it is, how much it weighs, etc. An attribute may describe why a relationship exists, how long it has existed, how long it will exist, or under what conditions it exists.

An attribute is an aspect or quality of an entity which describes it or its actions. An attribute may describe some physical aspect, such as size, weight or color, or an aspect of the entity's location such as place of residence or place of birth. It may be a quality such as the level of a particular skill, educational degree achieved, or the dollar value of the items represented by an order.

A characteristic:

A data element:

is the lowest meaningful item of information (i.e. telephone area code).

The ability to classify the membership of a set of objects (or in this case entities) or to distinguish sets of objects from each other is directly dependent upon the ability to collect data about each member, by which membership in the various classification groups can be assigned.

For example, the classification of companies by type of ownership is dependent upon having data bout each company which identifies its type of ownership.

The ability to maintain records about an object is dependent upon the ability to identify what must be kept in those records and to subsequently collect that data. The ability to retrieve that data, especially if it is extensive, is dependent upon the ability to classify, organize or categorize that data into meaningful groupings such that each item of data has a meaningful, logical place, close to data which is closely related to it either by existence dependence or by meaning dependence (the data elements all relate to the same idea, concept or aspect or action of the entity).

In the real world model for purposes of clarity we include all entities regardless of their purpose, and use. The relationships are the real world relationships and describe how the entities relate and interact with each other.

The data model by contrast makes a distinction between entities we are interested in because we collect data about them and entities we are interested in because they are carriers of data or forms and documents we use to collect data about other entities. The real world model describes the relationships between entities, by stating that one or more occurrences of this kind of entity must (or may) be related to one or more occurrences of that kind of entity. The data model describes the data we need to know about those relationships, and how we can determine which actual occurrences of one kind of entity are related to which actual occurrences of another kind of entity and under what conditions or subject to what qualifications.

Normally in the data model we ignore document entities which function purely as carriers of data about other real entities. We instead concentrated on the data they carry and what entities that data describes.

One of the primary techniques for data modeling both in framework development and in procedural development is the Entity-relationship model. The first two of the four Entity-Relationship model levels are used to develop the data framework. These were the enterprise level model and the entity-relationship level model and were described in earlier chapters. These models can be used at the framework level since they can be developed deductively, and from empirical evidence.

The remaining two models (the entity-relationship-attribute level model and the data element level are inductively developed at the detail design level and are dependent on the full description of the entity family classification structure and a complete set of user views or data event maps for their completion. A complete set of data event maps is necessary since it is only from the data event maps (each of which depicts a specific user task view) that we can develop the composite data model which is the entity family model and only by examining the complete set can we be sure we have identified every necessary characteristic, and its data content, and every relationship required by every task for data access. All data event maps are necessary because it is only be examining these maps that we can determine whether the data we identified deductively (future data needs not currently present, and future relationship needs not currently captured) can be captured and maintained on a practical basis.

Since the data model development at the entity-relationship-attribute level is an inductive process and is dependent upon determining the exhaustive set of data event maps and the exhaustive classification structure of each entity family it must be the last step in the design process.

The development of the Entity-Relationship model is a multilevel process where each level produces a clearer and more well-defined view of the proposed environment. The complete results of this modeling effort results in a series of leveled environmental descriptions, along with a diagrammatic representation of each level. These diagrammatic representations, the ER models, are descriptions of the entities, or real components, of the business environment and how they relate to each other.

On a regular basis the firm deals with customers products, employees, places, orders, shipments, etc. The firm collects data about these things, these entities, and stores that data in files. With few exceptions, it is the common data resource files of the firms which hold the descriptions of those entities in the form of collections of data items.

The ER models are not data structure models, but data descriptions of the entities of interest to the firm. These data descriptions also correspond to the data contents of the files and thus serve well as a mechanism for developing our data framework. And, although at their most detailed level they contain and identify data elements, and they are not data processing models. They are business models and as such, they model business environments and depict business components.

Entity-Relationship models consist of representations of the various levels and parts of the organization, from the strategic to the operational levels. Each of these leveled models represent the entities and relationships from the perspective of that level, and within a level the Entity-Relationship models represent the perspective of a one or more particular users at that level.

Although there are numerous variations of the Entity-Relationship Approach model notation, the three basic notational components of the Entity-Relationship model consist of symbols representing an entity, a relationship between two entities, and the attributes, or descriptors of either entities or relationships.

These symbols are:

1. Rectangles - Each unique entity type or entity subtype is represented by a rectangle which contains the name of that unique entity type or entity subtype.
2. Diamonds - Each relationship which exist between any two different entities or between two occurrences of the same entity is represented by a diamond which contains the name of that relationship.
3. Circles - Each unique attribute of either an entity or a relationship is represented by a circle which contains the name of that attribute.

The framework model depicts real world families of entities. At this level the entities have the widest possible definition and scope, while still maintaining the general physical and role characteristics of the individual entities which comprise them. These entity sets are treated as if there were no variations in type and as if each of their component entities were defined in a similar manner and behaved in a similar manner.

Just as we use the general term vendor to represent each (any every) kind of vendor and employee to represent each (and every) kind of employee, so to we use an even more general term to represent all the various kinds of people, places, thing, concepts and events of interest to the firm. Depending upon the model (since a different definition is used for each model - real world and data) the term, entity, thus represents either any one of the real world things in the real world model, or any one of the generalized collections of data we gather, record, and maintain in the data model.

At the framework level: - Entities are identified and named - Relationships are defined as either existing or not existing between any given pair of entities - All entities and relationships are viewed from a single perspective - Business rules stated are at a strategic or policy level and apply firmwide - Business activities are functional stated - Business entities are portrayed at a family, class or universal level. There is no differentiation between the various subtypes of a given entity, unless those differences have meaning at a firmwide, and a functional level.

In the classification model:

• The polyhierarchic structure of each entity family is defined
• Each relationship between the different kinds of kinds of entities or entity groups are identified and named
• Entity groups, kinds of groupings, aliases, parent-child, cousin to cousin and generation to generation relationships as identified in the structure may be firmwide or viewed from a variety of business unit, divisional or other organizational perspectives. These perspectives may cross functional or business unit boundaries
• Business rules represented by this classification structure are tactical and may apply firmwide or to a specific unit or set of units
• The classification structure(s) within each family must represent all needs of the firm and may be based on external and thus real world structural views, or internal and based upon firmwide, functional or user views
• Business entity groupings and hierarchic and polyhierarchic lineages may be portrayed at a global or universal level or may be differentiated into more restrictive subtypes which relate to the particular business unit

Entity-Relationship-Attribute Level

The analysis at the third, or Entity-Relationship-Attribute, level combines the work of the framework level with that of the classification model and the data event maps by adding characteristic groupings determined inductively into a classification structure determined deductively, and by adding characteristics and or attributes to both the entities and the relationships. A characteristic or attribute is represented by a circle attached directly to the entity or the relationship which it describes. The circle contains the name of the attribute. Attributes might be: identification information, residence information, physical description, inventory status, packaging information, hobbies, clothing sizes, etc.

The attribute names for an employee entity, might be very similar to the section or item headings on an employment application, or the section or item headings on the permanent employee record form. For a customer, they might be very similar to the section headings on a new account opening form, or on the customer record form.

For an entity, each attribute represents some grouping of data which is necessary, from a business perspective, to describe a physical or logical characteristic of the entity, or to describe some activity of the entity. For a relationship, each attribute represents some grouping of data which is necessary from a business perspective, to describe, qualify or maintain the named relationship between two entities.

The Entity-Relationship-Attribute model is an expansion of the Entity-Relationship model. Until this point the models have only identified the entities and relationships by name and context. For a given entity or relationship little is known about them other than their name, the obvious fact of their existence, and the fact that the firm is interested in them.

At the Entity-Relationship-Attribute level, entities and relationships are described in terms of their attributes, or characteristics. In other words, beyond knowing that the entity exists, we must also know what the entity looks like, how it is identified, and what it does. These descriptors or characteristics are called attributes. An attribute is thus any distinct aspect of the entity or relationship that is necessary to describe the entity or to qualify the relationship. The full description of an entity or relationship consists of the full set of attributes which describe that entity or relationship.

For an entity attribute to be significant it must relate directly to the entity, be completely dependent on the entity for its existence and meaning, and it must be definable in terms of one or more data elements. It is immaterial as to whether there are one or more data elements in an attribute, as long as the attribute applies to all instances of the entity being represented. Seen another way, an attribute is some distinct category of mutually related data, the sum of which describes something of interest about the entity. The identifiers (unique or otherwise) of an entity are a special form of attribute.

Entity attributes (Figure 20-1) represent:

• A physical characteristic of that entity - size, shape, weight or color
• An historical attribute - date of birth or date of hire
• A location attribute - place of residence, place of work, or place of birth - A non-physical characteristic - price
• An identifier - name, title
• An occupational characteristic - current position, skill possessed, training received, educational courses, etc.
• The intermediate or final results of some processing activities related to the entity
• Data which relates to some current state or condition of the entity, or to some past or future state or condition of the entity
• Data which relates to some current action taken by or against the entity, or to some past or future action taken by or against the entity

For an relationship attribute to be significant it must relate directly to the relationship, be completely dependent on the relationship for its existence and meaning, and it must be definable in terms of one or more data elements. It is immaterial as to whether there are one or more data elements in an attribute, as long as the attribute applies to all instances of the entity or relationship being represented.

Seen another way, an attribute is some distinct category of mutually related data, the sum of which describes something of interest, or some qualifier about the relationship between two entities. A relationship attribute must be dependent upon the connection between both entities and should be incapable of existence in the absence of that relationship. The minimum attributes of a relationship are the necessary identifiers of each entity of the related pair.

Relationship attributes (Figure 20-2) represent some descriptor or qualifier of the relationship such as:

• An historical attribute - date of marriage, or date of sale, date of storage
• An location attribute - place of storage, place of work, or place of birth
• A non-physical characteristic - price at time of sale, discount at time of sale, grade in course
• Some meaningful data which is not an attribute of either entity participating in the relationship, but pertains only to the relationship between them. This data is sometimes called intersection data.

It is possible for the same named attribute to be used to describe many different entities and relationships. Identifier attributes in particular describe both the entities and the relationships between them.

Entity-Relationship-Attribute Level Model

The creation of an Entity-Relationship-Attribute model is a multiple step process. This step produces the most detail model.

Step one extracts each entity from the Entity-Relationship model and places it at the top of a separate page. Each distinct relationship between each pair of related entities is extracted from the Entity-Relationship model, and placed at the top of a separate page.

Step two, identifies, names and defines each attribute of each entity. Each attribute, represented by an attribute symbol, is drawn below the entity symbol and is connected to the entity by a single line (Figure 20-3). As each attribute symbol is drawn, the attribute name should be placed within it. Although not a requirement, as each attribute is identified and named, it is helpful to annotate it with a discrete number or "n" (denoting some unknown number more than one) to indicate how many occurrences of this attribute would necessary to describe the entity.

Step three identifies, names and defines each attribute of each relationship. The attributes of a relationship are those categories of data which are necessary to qualify the relationship, describe when and under what conditions it occurs, and any other information which relates only to the connection between the entities and not to either entity independently. The relationship attributes should include all attributes necessary to clearly and completely identify the any qualifications of that particular relationship between the two entities and the conditions under which the relationship exists (Figure 20-4).

As each attribute is identified and named, it is be drawn below the relationship symbol and connected to the relationship by a single line. As with the attributes of entities, it is helpful to annotate the attribute with a discrete number or with "n", to identify the number of occurrences of this particular attribute which are necessary to fully describe or qualify the relationship.

As the attributes of each relationship are modeled, the relevant attributes of each of the entities of the related pair, which are of interest within the context of the relationship should be extracted from the attributed entity model and added to the entity symbols of the relationship model.

In data processing terms, and in a very general sense, the attributes within this model can be considered to be the identification and definition of the record types (or record groupings) which will ultimately contain the data elements. It must be noted that each attribute at either the entity or relationship level represents a mutually exclusive and mutually independent category of data. However, an attribute may or may not represent an actual record type.

In the logical data structure models, created at a later date from these Entity-Relationship-Attribute models, attributes may be combined to form records more general records, they may be kept separately or in some extreme cases because of the complexity of the attribute, an attribute may be split into many records. The names of the entities are the names of the logical data aggregates (or structures) of the environment.

A fourth, or data element, level may be added when the models are developed in conjunction with the data processing systems development projects. This is the level which is most familiar to data processing specialists and consists of identifying and defining the specific data elements which are needed to describe each attribute of each entity and each relationship. Data elements are assigned only to attributes. In a sense, data elements are the attributes of the attributes.

Additional Rules for ER Model Creation

Regardless of the level being addressed, the following rules apply to the construction of an Entity-Relationship diagram:

1. Entities:
   1. Each rectangle must represents a single entity, or a homogeneous group of entities or one subset or subtype of the entity.
   2. When developing detailed models, each identified global entity should be decomposed into its component subsets.
   3. The mode of decomposition is dependent upon the characteristics of the component entities and the requirements of the firm for information about those entities.
   4. Regardless of the mode of decomposition, care should be take to ensure that all entity subtypes can be related back to their base global entity. This may be accomplished by special notation or by including the name of the base entity within the entity subtype name
   5. When the model includes documents, each unique type of document should be included, and the attributes for these documents should include all data field content which must be validated, processed and retained by the firm
   6. When document processing requires that data be validated against preexistent reference files, code lists, spreadsheet or other financial tables, etc., the referenced data items should be treated as if they were entities and included in the model along with their appropriate attributes and relationships

   2. Relationships:

   1. Relationship diamonds are drawn between, and must be connected (by a line from each side of the diamond) to no less than one and no more than two entity rectangles
   2. A diamond may be connected back to the same entity, in which case it represents a recursive relationship between unique occurrences of the same entity
   3. Each diamond must represent a single relationship which is known to exist between the two connected entities and is of interest to the firm.
   4. For each line which connects the diamond to a rectangle, at the point where that line joins that rectangle a notation should be made as to whether the two entities being related have a one to one, one to many, many to one, or many to many relationship.
   5. This notation should be made in the form - a:b -
      where:
      
      a = the entity on the left side of the diamond
      b = the entity on the right side of the diamond and, a and b may have any numeric value equal to or greater than one, or N (denoting an indefinite number more than one)
   6. If the relationship is symmetrical, that is, entity A (the left hand entity) has the same relationship to entity B (the right hand entity), i.e. each A is connected to many B's and each B is connected to one and only one A, then the notation closest to each entity should be the same.
   7. If the relationship is asymmetrical, that is, entity A does not have the same relationship to entity B as entity B has to entity A, i.e. Each A is connected to one and only one B, but each B may be connected to many A's, that the notation closet to each entity should reflect the view from that entity to the opposite entity.

   3. Attributes:

   1. Circles representing attributes are connected to either rectangles or diamonds
   2. Each circle may be connected to one and only one rectangle or one and only one diamond and must represent a specific attribute, of the entity or relationship to which it is connected.
   3. The circles on the diagram contain a name which identifies the specific attribute or set of attributes being depicted
   4. The line connecting the circle to the entity or relationship should be annotated to reflect whether the named attribute may occur only once per entity (or relationship) or many times.
   5. Each Entity rectangle and Relationship diamond must have at least one associated attribute
   6. Attributes which apply to more than one entity, or to more than one relationship, must be diagramed as if they were unique to each entity or relationship to which they apply. This condition will occur when a global entity has been separated into entity subsets, and the members of one or more subsets share many of the same attributes. Under these conditions each occurrence of the attribute symbol should have the same name, and some notation which indicates that it is identical in format to attributes which appear elsewhere.

If all attributes and all relationships connected to the entity rectangle do not have the potential to apply equally to the each and every entity occurrences defined to it, then the definition of the entity being used must be changed and a new entity or entity set, or a new entity subset or subsets, must be created until this condition is satisfied.

Although the above discussion assumed that one and only one model will be created at each level, and for the firm as a whole, most projects are for specific user areas, it may be desirable to create different models for each user area.

Just as an entity can be viewed from many different perspectives, and may seem to be different from each perspective, so to Entity-Relationship and Entity-Relationship-Attribute models can be different from the various perspectives of the firm. Each area of the firm defines the entities of the firm in different ways, and relates to them in different ways.

All Entity-Relationship models need not contain every entity of the firm. The various models need only contain the entities of interest to the particular area being modeled. To illustrate:

1. A model can be built to reflect only the document entities, the entity sources for those documents, and the relationships between both types of entities.
2. A model might contain functional entities and their relationships. Here the functional areas of the firm (managerial concepts) are treated as entities themselves and the model reflects their relationships to each other.
3. Another variation might contain only the processing entities (groups of people, machines or work stations) and the document and or resource entities used by them. This type of model might reflect all the processing stations through which a particular document must travel, or the work stations through which a manufactured part must pass. A process model does not reflect what processing is done, or even how that processing is done, but rather a station where processing of a particular type is done. That processing could be complex or simple.

The various Entity-Relationship Approach models are business models, rather than data processing models. That is they reflect business environments, not methods of processing. The types of entities and relationships selected to be included in each model, the definitions of those entities, and the attributes used to describe those entities and relationships, all combine to describe the environment, and the nature of the business itself.

Data Directed Systems Design - A Professional's Guide
Written by Martin E. Modell
Copyright © 2007 Martin E. Modell
All rights reserved. Printed in the United States of America. Except as permitted under United States Copyright Act of 1976, no part of this publication may be reproduced or distributed in any form or by any means, or stored in a data base or retrieval system, without the prior written permission of the author.