Entities: strong vs weak, type vs instance

Type vs instance

An entity type is a collection of entities that share common properties — named with a singular noun in ALL CAPITALS (STUDENT, EMPLOYEE, AUTOMOBILE). It is the category definition, stored once as metadata. An entity instance is a single occurrence of that type — Michelle Brady, Employee #64217836 — and many instances are stored as data. This is exactly the class/object distinction from programming: the type is the structure (defined once), instances are the stored values (many). A common beginner error is to confuse instances with rows on a screen; keep them separate — the type lives in the schema, instances live in the data.

Not everything that appears in a requirements document is an entity. A genuine data entity has many possible instances, each with a distinguishing characteristic and other descriptive data. Three warning signs that something is not an entity: there is only one instance (a single user like the Treasurer), the data can be computed from other stored data (an Expense Report), or the would-be relationship names sound like processing (Receives, Summarizes) rather than association. Test question: would we ever store data about this that isn't already represented elsewhere?

Strong vs weak entities

This is the high-yield distinction.

• A strong entity type exists independently of other entity types and has its own unique identifier. STUDENT, EMPLOYEE, AUTOMOBILE — each can be uniquely identified on its own. On the diagram it is a single-lined rectangle.
• A weak entity type depends for its existence on another entity type — its identifying owner — and cannot be uniquely identified without it. DEPENDENT only has meaning in the context of EMPLOYEE.

A weak entity is recognized by three things that travel together:

1. an identifying owner (the strong entity it depends on),
2. a partial identifier (an attribute, drawn with a double underline, that is unique only within one owner — e.g. Dependent Name is unique only among one employee's dependents), and
3. an identifying relationship connecting the two.

The notation is the exam trap. A weak entity is drawn as a double-lined (double-walled) rectangle, and its identifying relationship is drawn with a double line. During logical design (Module 4), the weak entity's full key becomes partial identifier + the owner's identifier (e.g. Employee ID + Dependent Name).

Worked example — Employee / Carries / Dependent

Consider the diagram the sample exam puts in front of you: a single-lined Employee box connected by a relationship labeled Carries to a double-lined Dependent box.

Read it construct by construct. Employee is a single rectangle → a strong entity. Dependent is a double-walled rectangle → a weak entity. The double wall says: a dependent cannot be identified on its own — two different employees can both have a dependent named "Pat," so "Pat" is only a partial identifier, made unique by combining it with the owning Employee. Carries is therefore the identifying relationship between the strong owner and its weak entity. So the single correct reading of the figure is: "a strong entity (Employee) and its associated weak entity (Dependent)." Not a plain one-to-many, not a "co-dependent" or "double-walled" relationship — the double wall is on the entity, and it means weak.