Adding Attributes to the Model

Non-key attributes describe the entities to which they belong. In this section, we discuss the rules for assigning non-key attributes to entities and how to handle multivalued attributes.

Relate attributes to entities

Non-key attributes can be in only one entity. Unlike key attributes, non-key attributes never migrate, and exist in only one entity. from parent to child entities.

The process of relating attributes to the entities begins by the modeler, with the assistance of the end-users, placing attributes with the entities that they appear to describe. You should record your decisions in the entity attribute matrix discussed in the previous section. Once this is completed, the assignments are validated by the formal method of normalization.

Before beginning formal normalization, the rule is to place non-key attributes in entities where the value of the primary key determines the values of the attributes. In general, entities with the same primary key should be combined into one entity. Some other guidelines for relating attributes to entities are given below.

Parent-Child Relationships

• With parent-child relationships, place attributes in the parent entity where it makes sense to do so (as long as the attribute is dependent upon the primary key)
• If a parent entity has no non-key attributes, combine the parent and child entities.

Multivalued Attributes

If an attribute is dependent upon the primary key but is multivalued, has more than one value for a particular value of the key), reclassify the attribute as a new child entity. If the multivalued attribute is unique within the new entity, it becomes the primary key. If not, migrate the primary key from the original, now parent, entity.

For example, assume an entity called PROJECT with the attributes Proj_ID (the key), Proj_Name, Task_ID, Task_Name

PROJECT

Task_ID and Task_Name have multiple values for the key attribute. The solution is to create a new entity, let's call it TASK and make it a child of PROJECT. Move Task_ID and Task_Name from PROJECT to TASK. Since neither attribute uniquely identifies a task, the final step would be to migrate Proj_ID to TASK.

Attributes That Describe Relations

In some cases, it appears that an attribute describes a relationship rather than an entity (in the Chen notation of ER diagrams this is permissible). For example,

a MEMBER borrows BOOKS.

Possible attributes are the date the books were checked out and when they are due. Typically, such a situation will occur with a many-to-many relationship and the solution is the same. Reclassify the relationship as a new entity which is a child to both original entities. In some methodologies, the newly created is called an associative entity. See Figure 1 for an example of an converting a relationship into an associative entity.

Derived Attributes and Code Values

Two areas where data modeling experts disagree is whether derived attributes and attributes whose values are codes should be permitted in the data model.

Derived attributes are those created by a formula or by a summary operation on other attributes. Arguments against including derived data are based on the premise that derived data should not be stored in a database and therefore should not be included in the data model. The arguments in favor are:

• derived data is often important to both managers and users and therefore should be included in the data model.
• it is just as important, perhaps more so, to document derived attributes just as you would other attributes
• including derived attributes in the data model does not imply how they will be implemented.

A coded value uses one or more letters or numbers to represent a fact. For example, the value Gender might use the letters "M" and "F" as values rather than "Male" and "Female". Those who are against this practice cite that codes have no intuitive meaning to the end-users and add complexity to processing data. Those in favor argue that many organizations have a long history of using coded attributes, that codes save space, and improve flexibility in that values can be easily added or modified by means of look-up tables.

Including Attributes to the ER Diagram

There is disagreement about whether attributes should be part of the entity-relationship diagram. The IDEF1X standard specifies that attributes should be added. Many experienced practitioners, however, note that adding attributes, especially if there are a large number, clutters the diagram and detracts from its ability to present the end-user with an overview of how the data is structured.

Summary

By the end of this stage you should have:

1. identified, named, and defined data objects and relationships
2. recorded information about data objects and relationships in the data document
3. created and refined the ER diagram
4. assigned attributes to entities
5. added attributes to ER diagram (optional)

The next section discusses Generalization Hierarchies.