Entity Instances in Database Design: An Employee Example

One Employee Type, Three Example Instances

The illustration preserves three example employees from the earlier diagram. These names and addresses are teaching data, not verified personnel or address records. The same information appears below as accessible table text.

All three instances share an attribute structure. They do not share the same values. EmployeeID 15502 identifies the instance whose Name value is Randy Masters, whose Street value is 14 Broadway Ave., and whose City value is New Orleans.

The City values are not the names of entity types in this diagram. San Diego is a value describing Beth's record, not a category containing a separate kind of employee. Explicit labels make that distinction easier to see than an unlabeled collection of names and addresses.

What Exactly Is an Entity Instance?

Describe an Instance with a Complete Sentence

A useful description states the type, identifier, and relevant values: “Employee 17244 has the name Luke Santana, street value 2605 W. Plainfield, and city value Philadelphia.” The identifier anchors the statement to one instance, while the other attributes say something about it.

“Philadelphia” alone is not an employee instance. Neither is the attribute name City. A value only becomes a specific recorded fact when you know which attribute and which instance it belongs to. The same city could describe hundreds of employees.

Likewise, an employee's name is not necessarily enough to identify one instance. Two people can share the same name. The system needs an identifier whose uniqueness follows an explicit rule rather than an assumption based on a small sample.

You do not need to list every attribute every time you refer to an instance. A screen may show only EmployeeID and Name. That abbreviated view still refers to the same stored employee, provided it retains enough context to distinguish the intended record.

Instances and ER Diagrams Serve Different Purposes

Decide What One Row Represents

For this lesson, assume the Employee table keeps one current record per employee identity. Under that assumption, three rows represent three employee instances. The same conclusion does not apply automatically to every table containing an EmployeeID column.

An EmploymentEpisode table might record separate periods of employment. A person who leaves and is rehired could have two episode rows while retaining one employee or person identity. An AddressHistory table might have several dated addresses for the same employee. Those rows describe different kinds of occurrences.

This level of detail is often called the table's grain. State it in plain language: one row per employee, one row per employment episode, or one row per address period. Choose the identifier and uniqueness rules to match that statement.

If a database contains 10,000 people, it does not necessarily contain exactly 10,000 rows across its employee-related tables. History, assignments, and contacts can add many more rows. Counting rows is meaningful only after identifying what each row represents and which records the query includes.

A similar distinction applies outside personnel data. One customer can place many orders, and one order can contain many order lines. Customer, Order, and OrderLine instances answer different questions even though their records are related.

Store the Employee Instances in a Table

The following illustrative PostgreSQL 18 example implements the four attributes shown in the diagram. EmployeeID values are supplied explicitly to match the teaching data. Name is required for this example; Street and City may be absent. A production system would define its address and naming requirements more carefully.

CREATE TABLE Employee (
    EmployeeID INTEGER PRIMARY KEY,
    Name       VARCHAR(200) NOT NULL,
    Street     VARCHAR(200),
    City       VARCHAR(100)
);

INSERT INTO Employee (EmployeeID, Name, Street, City)
VALUES
    (11672, 'Beth Johnson', '419 S. Presa', 'San Diego'),
    (15502, 'Randy Masters', '14 Broadway Ave.', 'New Orleans'),
    (17244, 'Luke Santana', '2605 W. Plainfield', 'Philadelphia');

SELECT EmployeeID, Name, Street, City
FROM Employee
WHERE EmployeeID = 15502;

The expected result is Randy Masters' row with Street 14 Broadway Ave. and City New Orleans. This follows from the sample statements; it is not a captured execution result. The identifier selects at most one stored Employee row because it is the primary key.

The chosen column sizes are illustrative, not universal limits for names or addresses. The following lesson on attribute domains and data types explains how permitted values and their representations should be defined.

Queries Can Show Only Part of an Instance

SELECT EmployeeID, Name
FROM Employee
ORDER BY EmployeeID;

Updating Values Does Not Normally Create a New Instance

Suppose Beth moves to a different city. If the table stores current address information, updating her descriptive values leaves EmployeeID 11672 attached to the same employee identity. Changing a fact about an instance is different from adding another instance.

UPDATE Employee
SET Street = '10 Example Lane',
    City = 'Example City'
WHERE EmployeeID = 11672;

This hypothetical update changes the current record. The diagram continues to show the original sample values. If the application needs to answer where Beth lived previously, replacing the values alone is insufficient; it needs a deliberate history design.

A historical row records a version or time-bounded fact about the employee. It should include the information needed to distinguish that historical occurrence, such as its own identifier or a suitable combination of employee and effective-time attributes. Historical versions should not be counted as new people merely because they occupy separate rows.

Deletion also follows business rules. An employee leaving the organization may call for an employment end date or inactive status rather than deleting every reference to that employee. Decide what the system must retain and what each status means before treating deletion as the default end of an instance's lifecycle.

Keys and Constraints Protect Declared Rules

The primary key rejects repeated EmployeeID values and prevents missing identifiers. A required Name column rejects NULL for that attribute. These are specific guarantees; they do not establish that an address is real, a name is correctly spelled, or every represented employee is eligible for a business process.

Nor does assigning different IDs automatically prevent duplicate records for the same person. Two records could contain the same descriptive values and different identifiers. They might be duplicate entries, or they might represent different people. Resolving that ambiguity needs appropriate business evidence and review.

Foreign keys help preserve references between related records. If an assignment must refer to an existing employee, a foreign key can enforce that relationship. Required participation, allowed assignment dates, and other rules need their own definitions and enforcement.

The important principle is to state each rule precisely rather than saying that constraints make every instance “valid.” They enforce the rules actually declared. Revisit identifier design rules and entity and attribute constraints for those complementary topics.

Common Misunderstandings About Instances

Check the Model with Sample Instances

Review examples that challenge assumptions as well as ordinary records. Consider two employees with the same name, an employee without a known address, someone with several contact addresses, and someone who leaves and returns. Ask whether the existing attributes and identifiers can represent each case without changing their meaning.

If one employee can have several independently maintained addresses, repeating columns such as Address1, Address2, and Address3 may impose an arbitrary limit. A related address structure may be more appropriate. The later lesson on resolving multivalued attributes explores that design decision.

As a short self-check, describe the middle card in one sentence. It is Employee instance 15502, named Randy Masters, with the displayed Street and City values. Name the type separately from those values, then explain why changing the city would not normally change the identifier.

For additional reading: Database Systems.

From Instances to Attribute Domains