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*.