LECTURE 10 | ENTITY TYPES & ENTITY SETS | CONCEPT OF KEY ATTRIBUTES | REAL LIFE EXAMPLES
NOTES LINK: https://drive.google.com/file/d/124Di...
Entity Types and Entity Sets. A database usually contains groups of entities that
are similar. For example, a company employing hundreds of employees may want to
store similar information concerning each of the employees. These employee entities
share the same attributes, but each entity has its own value(s) for each attribute. An
entity type defines a collection (or set) of entities that have the same attributes. Each
entity type in the database is described by its name and attributes. Figure 3.6 shows
two entity types: EMPLOYEE and COMPANY, and a list of some of the attributes
for each. A few individual entities of each type are also illustrated, along with the
values of their attributes. The collection of all entities of a particular entity type in the database at any point in time is called an entity set or entity collection; the entity set
is usually referred to using the same name as the entity type, even though they are
two separate concepts. For example, EMPLOYEE refers to both a type of entity as
well as the current collection of all employee entities in the database. It is now more
common to give separate names to the entity type and entity collection; for example
in object and object-relational data models (see Chapter 12).
An entity type is represented in ER diagrams5 (see Figure 3.2) as a rectangular box
enclosing the entity type name. Attribute names are enclosed in ovals and are
attached to their entity type by straight lines. Composite attributes are attached to
their component attributes by straight lines. Multivalued attributes are displayed in
double ovals. Figure 3.7(a) shows a CAR entity type in this notation.
An entity type describes the schema or intension for a set of entities that share the
same structure. The collection of entities of a particular entity type is grouped into
an entity set, which is also called the extension of the entity type.
Key Attributes of an Entity Type. An important constraint on the entities of an
entity type is the key or uniqueness constraint on attributes. An entity type usually
has one or more attributes whose values are distinct for each individual entity in the
entity set. Such an attribute is called a key attribute, and its values can be used to
identify each entity uniquely. For example, the Name attribute is a key of the
COMPANY entity type in Figure 3.6 because no two companies are allowed to have
the same name. For the PERSON entity type, a typical key attribute is Ssn (Social Security
number). Sometimes several attributes together form a key, meaning that the
combination of the attribute values must be distinct for each entity. If a set of attributes
possesses this property, the proper way to represent this in the ER model that
we describe here is to define a composite attribute and designate it as a key attribute
of the entity type. Notice that such a composite key must be minimal; that is, all
component attributes must be included in the composite attribute to have the
uniqueness property. Superfluous attributes must not be included in a key. In ER
diagrammatic notation, each key attribute has its name underlined inside the oval,
as illustrated in Figure 3.7(a).
Specifying that an attribute is a key of an entity type means that the preceding
uniqueness property must hold for every entity set of the entity type. Hence, it is a
constraint that prohibits any two entities from having the same value for the key
attribute at the same time. It is not the property of a particular entity set; rather, it is
a constraint on any entity set of the entity type at any point in time. This key constraint
(and other constraints we discuss later) is derived from the constraints of the
miniworld that the database represents.
Some entity types have more than one key attribute. For example, each of the
Vehicle_id and Registration attributes of the its own right. The Registration attribute is an example of a composite key formed
from two simple component attributes, State and Number, neither of which is a key
on its own. An entity type may also have no key, in which case it is called a weak
entity type (see Section 3.5).
In our diagrammatic notation, if two attributes are underlined separately, then each
is a key on its own. Unlike the relational model (see Section 5.2.2), there is no concept
of primary key in the ER model that we present here; the primary key will be
chosen during mapping to a relational schema (see Chapter 9).