Entities, Entity Sets and Entity Types

An entity is a distinguishable thing the database stores facts about, an entity type is its definition, and an entity set is the collection of entities of that type existing right now.

Concept

The entity relationship model is a high level design notation. You draw it before any table exists, agree it with the people who asked for the system, and only then convert it into tables.

It has exactly three building blocks: entities, attributes and relationships. This note covers the first.

Entity, entity type and entity set

TermMeaningExample
EntityOne distinguishable thing, real or conceptual, that the database stores facts about.The student with roll number 21
Entity typeThe definition: a name plus the attributes every entity of that kind has.STUDENT ( roll_no, name, dob )
Entity setThe collection of all entities of that type in the database at one moment.All 4,000 students currently enrolled
Entity type is to entity set as schema is to instance. The type is the stable definition; the set is what happens to exist today. Exams frequently ask this in exactly that form.
   ENTITY TYPE                  ENTITY SET
   (definition, stable)         (contents, changing)

   +---------------+            21  Meera   2007-04-11
   |    STUDENT    |            22  Ravi    2006-12-30
   +---------------+            23  Anitha  2007-01-19
   roll_no, name, dob                  ...
                                each row is ONE ENTITY

   In an ER diagram an entity type is drawn as a RECTANGLE.

What qualifies as an entity

Something is worth making an entity type when all three hold:

  1. It has independent existence in the mini world being modelled.
  2. It has attributes worth storing — more than just a name.
  3. Instances are distinguishable from each other.

Entities are not always physical. STUDENT and BOOK are tangible; COURSE, LOAN, ADMISSION and BOOKING are conceptual, and are entities in exactly the same way.

Entity or attribute? The decision that matters

This is the single most common ER design mistake, so it deserves a rule.

Make it an ENTITY when:            Keep it an ATTRIBUTE when:

 it has attributes of its own        it is a single value with
   department has a head,             no further detail
   a block, a phone                   date of birth, marks

 it is shared by many entities      it belongs to exactly one
   many students in one               entity and is never
   department                         referenced elsewhere

 the number of them varies          there is exactly one
   a student may have several         a student has one
   phone numbers                      roll number

 you would otherwise repeat         no repetition results
   the same value in many rows

Worked decision. Should department be an attribute of STUDENT or an entity type?

  • A department has a name, a head and a building — attributes of its own. Point one says entity.
  • Many students share one department. Point two says entity.
  • Storing the department name against every student repeats it 400 times. Point four says entity.

So DEPARTMENT is an entity type, and STUDENT is related to it. Storing dept_name as a plain attribute of STUDENT would produce exactly the update anomalies that Phase 8 spends its time removing.

Notation

SymbolMeans
RectangleEntity type
Double rectangleWeak entity type
EllipseAttribute
DiamondRelationship type
LineConnects an entity to its attributes or to a relationship

Example

   A first fragment of a college model

        +-----------+                 +--------------+
        |  STUDENT  |                 |  DEPARTMENT  |
        +-----------+                 +--------------+

   entity type   STUDENT
   entity set    every student currently enrolled
   one entity    the student with roll number 21

   entity type   DEPARTMENT
   entity set    the six departments that exist
   one entity    the Computing department

Common mistakes

  • Using entity and entity set interchangeably. One is a single thing, the other is the whole collection.
  • Making everything an entity. A date of birth has no attributes of its own and is not shared. It is an attribute.
  • Making a shared, detailed thing an attribute. This is the error that causes redundancy, and it is the one examiners look for.
  • Assuming entities must be physical objects. An enrolment, a loan and a booking are entities.

Exam and interview questions

  1. Define entity, entity type and entity set with one example each.
  2. How does an entity type relate to a schema, and an entity set to an instance?
  3. State four tests for deciding whether something should be an entity or an attribute.
  4. Give an example of a conceptual entity that has no physical existence.
  5. Why does modelling department as an attribute of student cause problems?

Practice

  1. For a hospital, list six entity types and say which are physical and which are conceptual.
  2. Decide with reasons whether each should be an entity or an attribute: address, supplier, semester, phone number, designation.
  3. Write the entity type, the entity set and one entity for a library book.

Conclusion

An entity is one thing, an entity type is its definition, and an entity set is the current collection. The judgement that matters most is entity versus attribute — decide it with the four tests, and the rest of the design gets easier.

Written by Lorens Mishra

Software Engineer Notes Management System Administrator

Continue reading

All DBMS notes →
DBMS

Keys in the ER Model

A key attribute distinguishes one entity from another. Understanding super keys, candidate keys, primary keys and partial keys at design time prevents...

Read more

Discussion

0 comments
Sign in to join the discussion.

No comments yet. Be the first to say something.