Entities and Attributes | Databases

Origins of ER modelling

Entity-Relationship (ER) diagrams are a conceptual modelling technique introduced by Peter Chen in 1976. They provide an implementation-independent way to describe the data we intend to store in a database. Although ER modelling grew up around relational database systems, it helps clarify design issues for any data model: it forces you to think about what the data means before you commit to tables, columns, or SQL.

The key insight is that ER diagrams are not tied to a particular DBMS, storage engine, or even the relational model. They capture the conceptual schema — the logical structure of the data as understood by the domain expert — and this schema can later be mapped to a relational schema, a document store, or a graph database.

Entities

Entities represent the nouns of our domain — the real-world objects or concepts we want to record information about. In an ER diagram, entities are drawn as rectangles labelled with the entity type name.

Domain	Example entities
Film database	Movie, Person, Studio, Genre
University	Student, Module, Lecturer, Department
E-commerce	Customer, Order, Product, Supplier

An entity set is the collection of all instances of a given entity type at a particular moment. For example:

Movie = {(tt0113189, GoldenEye, 1995),
         (tt0988045, Sherlock Holmes, 2009),
         (tt0371746, Iron Man, 2008)}

Each member of the entity set is an entity instance (or simply an entity). The data model does not need to enumerate every possible instance; it only specifies the structure that any valid instance must conform to.

Attributes

Attributes represent the properties of an entity — the facts we want to record about each instance. In an ER diagram, attributes are drawn as ovals connected to their entity rectangle.

A Movie entity might have attributes: title, release_year, running_time, budget. Each attribute draws its values from a domain (a set of permissible values). The domain of release_year might be {1888, 1889, ...}; the domain of title might be variable-length strings.

Keys

A key is an attribute (or set of attributes) whose value uniquely identifies each entity instance within an entity set. In ER diagrams, key attributes are underlined.

A key must satisfy two properties:

Uniqueness: no two distinct entities in the set may have the same key value.
Minimality (ideal): no attribute can be removed from the key without destroying uniqueness.

Keys may be formed algorithmically. A CRSID (e.g., abc123) is a key for Cambridge students: it is assigned by the University and is unique within that namespace. However, relying on keys that lie outside your control is dangerous. A National Insurance number might seem like a convenient natural key, but:

You do not issue or manage NI numbers; they can be reassigned under exceptional circumstances.
The format could change.
Not everyone in your system will have one (e.g., international customers).
Data entry errors are irreversible if the key is used as a foreign key throughout the schema.

Synthetic keys

In practice, the only safe thing to use as a primary key is a synthetic key (also called a surrogate key): an identifier that is automatically generated by the database and has no meaning outside the database itself. Common examples:

Type	Example	Notes
Auto-increment integer	`1, 2, 3, ...`	Simple, fast, but reveals insertion order
UUID (v4)	`550e8400-e29b-...`	Globally unique, larger storage cost
ULID	`01ARZ3NDEKTSV4R...`	Time-sortable, URL-safe

The important principle: a synthetic key is an internal implementation detail. Users of the system should never see it, type it, or depend on it staying the same across database migrations. It exists purely to give each row a stable, unique address within the database.

Scope of the model

An ER diagram implicitly declares the scope of the model. Among the infinitely many possible attributes a real-world entity possesses, the diagram selects only those relevant to the application. A Movie has a plot synopsis, a colour grading, a distribution contract — but if your database is a simple viewing tracker, you model only title, year, and genre. The attributes you choose to include (and, just as importantly, to exclude) define the boundary of what your system knows about.

Summary

ER diagrams are a conceptual design tool, independent of any particular DBMS.
Entities (rectangles) are the objects we model; attributes (ovals) are their properties.
A key (underlined) uniquely identifies each entity instance.
Synthetic keys are safer than natural keys because they are under the database’s sole control.
The model’s scope is a design decision: you declare which attributes matter for your application.