Modeling Entities and

Attributes
2.2 Modeling Entities and Attributes
•The basic constructs of the entity-relationship model are entities, relationships and attributes.
•The richness of the E-R model allows designers to model real world situations accurately and
expressively which helps account for the popularity of the model.
2.1.2 Entities
An entity is a person, place, object, event or concept in the user environment about which the
organization wishes to maintain data. Some examples of each of these types of entities follow:
PERSON: EMPLOYEE, STUDENT, PATIENT.
PLACE: STORE, WARE HOUSE AND STATE.
OBJECT: MACHINE, BULILDING, AUTOMOBILE.
EVENT: SALES, REGISTRATION, RENEWAL
CONCEPT: ACCOUNT, COURSE, WORK CENTER.
Entity Types Vs Entity Instance

•There is an important distinction between entity types and entity

instance. An entity type is a collection of entity instances that
share common properties or characteristics.
•Each entity type in an E-R model is given a name. Since the name
represents a collection (or set) of items, it is always singular. We
use capital letters for names of entity type(s). In an E-R model
diagram the entity name is placed inside the box representing the
entity type.
•An entity instance is a single occurrence of an entity type.
Entity Types Vs Entity Instance

•Figure 2-3 illustrates the distinction between an entity type and

two of its instances.
•An entity type is described just once (using metadata) in a
database, while many instances of that entity type may be
represented by data stored in the database.
•For example, there is one EMPLOYEE entity type in most
organizations, but there may be hundreds (or even thousands) of
instances of this type stored in the database. We often use the
single term “entity” rather than entity instance.
Figure 2‑3Entity type EMPLOYEE with two instances
Entity Type Vs System Input, Output or
User

•A common mistake made when people are just learning to draw

E-R diagrams, especially if they already are familiar with data
process modeling (such as data flow diagramming), is to confuse
data entities with other elements of an overall information
systems model.
•A simple rule to avoid such confusion is that a true data entity will
have many possible instances, each with distinguishing
characteristics as well as one or more descriptive pieces of data.
Figure 2‑4Inappropriate Entities
•Consider figure 2-4, which might be drawn to represent a database needed for a
college sorority’s expense system.
•In this situation, the sorority treasure manages accounts, receives expense
reports and records expense transactions against each account.
•However, do we need to keep track of data about the treasurer (the TREASURER
entity type) and her supervision of accounts (that Manages relationship) and
receipt of reports (the Receives relationship).
•The Treasurer is the person entering data about accounts and expenses and
receiving expense reports. That is, she is a user of the database.
•Since there is only one Treasurer, TREASURER data do not need to be kept.
Further, is the EXPENSE REPORT entity necessary?
•Since an expense report is computed from expense transactions and account
balances, it is the result of extracting data from expense transactions and
account balances and received by the Treasurer.
•Even though there will be multiple instances of expense reports given to the
Treasurer over time, data needed to compute the report contents each time are
already represented by the ACCOUNT and EXPENSE entity types.
Figure 2‑5Appropriate Entities
Figure 2-5 shows entities and relationship that would be sufficient to handle the sorority
expense system.
2.1.3 Attributes

•Each entity type has a set of attributes associated with it. An attribute is a property or
characteristics of an entity type that is of interest to the organization.
•Following are some typical entity types and their associated attributes.
STUDENT: Student_ID, Student_Name, Home_Address, Phone_Number, Major
AUTOMOBILE: Vehicle_ID, Color, Weight, Horsepower
EMPLOYEE: Employee_ID, Employee_Name, Payroll_Address, Skill

•In naming attributes, we use an initial capital letter followed by lowercase letters.
•If an attribute name consists of two words, we use an underscore character to connect
the words and we start each word with a capital letter; for example: Employee_Name.
•In E-R diagrams, we represent an attribute by placing its name in the entity it
describes. Attributes may also be associated with relationships. Note that an
attribute is associated with exactly one entity or relationship.
•Each entity (or instance of an entity type) has a value associated with each of
the attributes of that entity type.
•An attribute that must be present for each entity instance is called a required
attribute, whereas an attribute that may not have a value is called optional
attribute.
•For example, Figure 2-7 shows two STUDENT entities (instances) with their respective attribute
values. The only optional attribute for STUDENT is Major. (Some students, specifically Melissa
Kraft in this example, have not chosen a major yet.)
•However, every student must, by the rules of the organization, have values for all other
attributes.
•A database is, in essence, the collection of all attribute values for all of the entities; an attribute
without value is said to be null.
•Thus, each entity has an identifying attribute plus one or more other attributes.
•If you try to create an entity that has only an identifier, then that entity is likely not legitimate.
Such a data structure may simply hold a list of legal values for some attributes, which is better
kept outside the database.
Figure 2‑7Entity type Student with Required
and Optional Attributes
Simple Versus Composite Attributes
•Some attributes can be broken down into meaningful component, detailed parts.
•The most common example is Address, which can usually be broken down into the following
components: Street_Address, City, State and Postal_Code.
•A composite attribute is an attribute (such as Address) that has meaningful component parts.
Figure 2-8 shows the notation for composite attributes.
•Composite attributes provide considerable flexibility to users, who can either
refer to the composite attribute as a single unit or else refer to individual
components of that attribute.
• Thus, for example, a user can either refer to Address or refer to one of its
components, such as Street_Address.
•The decision whether to subdivide an attribute into its component parts
depends on whether users will need to refer to those individual components,
and hence they have organizational meaning.
•A simple (or atomic) attribute is an attribute that cannot be broken down into
smaller components. For example, all of the attributes associated with
AUTOMOBILE are simple: Vehicle_ ID, Color, Weight, and Horsepower.
Single-Valued Versus Multivalued
Attributes
•Figure 2-7 shows two entities with their respective attributes values. For each entity
instance, each of the attributes in the figure has one value.
•It frequently happens that there is an attribute that may have more than one value for
a given instance.
•For example, the EMPLOYEE entity type in figure 2-9 has an attribute named Skill,
whose values record the skill (or skills) for that employee. Of course, some employees
may have more than one skill (such as PHP Programmer and C++ Programmer).
•A multivalued attribute is an attribute that may take on more than one value for a
given entity (or relationship) instance.
•We indicate a multivalued attribute with curly brackets around the attribute name, as
shown for the Skill attribute in the EMPLOYEE example in Figure 2-9.
Figure 2‑9Entity with multi-valued attribute
(Skill) and Derived Attribute (Years
Employed
Stored Versus Derived Attributes
•Some attribute values that are of interest to users can be calculated or derived
from other related attribute values that are stored in the database.
•For example, suppose that for an organization, the EMPLOYEE entity type has a
Date_Employed attribute. If users need to know how many years a person has
been employed, that value can be calculated using Date_Employed and today’s
date.
•A derived attribute is an attribute whose values can be calculated from related
attribute values (plus possibly data not in the database, such as today’s date,
the current time).
•We indicate a derived attribute in an E-R diagram by using square brackets
around the attribute name, as shown in Figure 2-9 for the Years_Employed.
Identifier Attribute
•An identifier is an attribute (or combination of attributes) that uniquely identifies
individual instance of an entity type.
•That is now two instances of the entity type may have the same value for the identifier
attribute.
•The identifier for the STUDENT entity type is Student_ID, while the identifier for
AUTOMOBILE is Vehicle_ID.
•Notice that an attribute such as Student_Name is not a candidate identifier, since
many students may potentially have the same name and students, like all people, can
change their names.
•To be a candidate identifier, each entity instance must have a single value for the
attribute and the attribute must be associated with the entity.
•We underline identifier names on the E-R diagram, as shown in the example in Figure
2-10.
•To be an identifier, the attribute is also required (so the distinguishing value must
exist).
•For some entity type, there is no single (or atomic) attribute that can serve as the
identifier (that is, will ensure uniqueness).
•However, two (or more) attributes used in combination may serve as the identifier.
•A composite identifier is as identifier that consists of a composite attribute.
•Figure 2-10 shows the entity FLIGHT with the composite identifier Flight_ID. Flight_ID
in turn has component attributes Flight_Number and Date.
•This combination is required to uniquely identify individual occurrence of FLIGHT. We
use the convention that the composite attribute (Flight_ID) is underlined to indicate it
is the identifier, while the component attributes not underlined.
Figure 2‑10Simple and Composite Identifier
Attributes