The attribute taxonomy

An attribute lives on several axes at once

An attribute is a property of an entity type (or relationship type) that is of interest to the organization. Attribute names use Initial Capitals With Spaces (Employee Name, Student Home Address) — contrast entity types, which are ALL CAPS. A core principle of the E-R model: each attribute belongs to exactly one entity or relationship — the model is non-redundant by design. Every attribute can be classified on several independent axes, and the exam loves asking you to classify a list and give your own example of each.

Simple (atomic) vs composite. A composite attribute has meaningful component parts — Address breaks into Street, City, State, Postal Code. A simple/atomic attribute cannot be usefully subdivided — Horsepower, Weight. The deciding question: will users ever need the parts separately? If yes, model it composite.

Single-valued vs multivalued. A multivalued attribute can hold more than one value for a single instance — one Employee may have several Skills. It is drawn with curly braces around the name: {Skill}. (Note: multivalued ≠ composite. Composite = one value with parts; multivalued = several values. You can even have a multivalued composite, like an Employee's several phone entries each split into area code + number.)

Stored vs derived. A derived attribute's value is calculated from other stored values — Years Employed derived from Date Hired and today's date. It is drawn with square brackets: [Years Employed]. Storing vs deriving is a trade-off: storing wastes space and risks going stale; deriving costs compute on every read.

Required vs optional. A required attribute must have a value for every instance; an optional one may be null. An identifier is always required. (A pattern of optionals can hint at hidden subtypes — see Module 3.)

Identifier and composite identifier. An identifier uniquely distinguishes each instance and is shown underlined. A composite identifier needs more than one attribute combined — e.g. a Flight ID made of Flight Number + Date; the composite is underlined, its parts are not. A good identifier is stable (never changes), complete (never null), and non-intelligent (its structure does not encode meaning that could change — avoid codes whose first two digits mean "department").

Worked example — classify a list

For a CAR entity, classify each attribute:

• VIN → the identifier (underlined): unique, stable, complete.
• Color → simple, single-valued, stored.
• Manufacturer Address → composite (Street, City, State, Postal Code) and stored.
• {Optional Feature} → multivalued (a car can have several): drawn {Optional Feature}.
• [Age] → derived from Year of Manufacture and the current year: drawn [Age].
• Trim Level → optional (a base model may have none) and simple.

Notice the axes are independent: Manufacturer Address is composite and single-valued and stored; an attribute could be a multivalued composite. Classify on each axis separately and you will never be wrong.