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.