In entity-relationship modeling, what do the terms simple, composite, multivalued and derived attribute mean? Give an example of each.
answer
- simple = atomic value
- composite = named group of parts
- multivalued = set at one moment
- derived = computed, may drift
- atomic is domain-relative
basics
~20 sSimple: one atomic value (birth date). Composite: a named group of simpler parts (full name = first + last). Multivalued: several values at once for one instance (phone numbers). Derived: computable from other stored data (age from birth date).
solid answer
~50 s**Simple (atomic)** attributes hold one indivisible value — an order's placed-at timestamp. **Composite** attributes have internal structure you sometimes address as a whole and sometimes by part: full name, or an address made of street, city, postcode. Whether you keep it as one unit or break it up depends on whether anything queries the parts. **Multivalued** attributes hold a set of values for a single instance at the same moment — a person's phone numbers or skills. They are a flag that something extra is going on, because a value set does not fit inside one instance-level fact. **Derived** attributes are computed from other data rather than independently asserted: age from date of birth, an order total from its lines. They are worth marking as derived precisely because storing them creates a value that can disagree with its source. The taxonomy matters because each kind behaves differently when the model becomes a physical schema, and multivalued and derived both hide an explicit decision.
go deeper
Give the four definitions and one crisp example each; that alone is a pass at this level.
Add why the classification exists: multivalued and derived each hide a design decision, and atomicity depends on the domain.
Talk about consequences — repeating slots and delimited strings as failure modes, and the maintenance contract you take on when you store a derived value.
Frame derived attributes as a consistency-versus-cost tradeoff and discuss where the recompute obligation lives — write path, background job, or read-time view — and how staleness is bounded.
## Why classify attributes at all An attribute is a fact about one entity instance. Classifying attributes at conceptual-modelling time surfaces decisions that are cheap to make on a whiteboard and expensive to discover later. ## Simple (atomic) A simple attribute holds a single indivisible value: a birth date, a quantity, a status. "Indivisible" is domain-relative — a phone number is atomic to most applications but composite to a telecom that reasons about country code, area code and subscriber number separately. The practical test is whether the business ever needs a part on its own. ## Composite A composite attribute is a named group of simpler attributes treated as a unit: FullName over first/middle/last, Address over street/city/postcode. Marking it composite records that the parts belong together and gives you a choice later: keep the whole as one value, or expose the parts. Anything you filter, sort, group or validate by must be exposed as its own part — keeping addresses in a single free-text blob is the classic version of getting this wrong, because "all customers in one city" becomes string matching. ## Multivalued A multivalued attribute holds a set of values for one instance simultaneously: phone numbers, email addresses, tags, skills. It is not the same as a value that changes over time — that is a history, modelled with time-stamped facts. Multivalued attributes matter because the relational model has no room for a set inside a single fact, so every multivalued attribute is a deferred decision. Symptoms of ducking it are repeating slots (phone1, phone2, phone3), which cap the count and make "find the customer with this number" awkward, or a delimited string, which defeats typing, uniqueness and per-value constraints. Notice too that once you want to describe each value — a phone's type, verified flag, primary flag — the multivalued attribute is really an entity trying to emerge. ## Derived (computed) A derived attribute is a function of other data already in the model: age from date of birth and today, order total from the sum of line amounts, a customer's order count. The model should mark it as derived so a reader knows it is not an independent assertion of fact. Two consequences follow. First, correctness: any stored copy can drift from its source unless something keeps them in step, so if you store it you owe the design a mechanism and a story for what happens when the source changes retroactively. Second, cost: recomputing is cheap for age and expensive for an aggregate over millions of rows, which is the whole reason materialised copies exist. The conceptual model does not decide store-versus-compute; it just makes sure nobody forgets that a decision is owed. ## Two more terms that travel with these A **key attribute** is one whose value identifies the instance among all instances of its entity. An **optional** attribute is one that may legitimately have no value for some instances — worth recording separately from the four kinds above, because optionality is about presence, not structure. ## Putting it together On a single Customer entity you might have a simple attribute (signup date), a composite one (name), a multivalued one (phone numbers), a derived one (lifetime spend) and an optional one (nickname). Naming the kinds is not academic ceremony: three of those five carry an open design question, and the taxonomy is how you make sure the question gets asked.
- How is a multivalued attribute different from an attribute whose value changes over time?A multivalued attribute holds several values simultaneously — a customer has three phone numbers right now. A changing value has exactly one value at any instant, with earlier values belonging to history. They look similar in a snapshot but need different models: a set of current values versus time-stamped facts with valid-from and valid-to periods.
- When would you store a derived attribute rather than compute it on demand?When the computation is expensive or the value must be frozen. Aggregates over large volumes read far cheaper when maintained, and a figure such as the tax charged on an invoice must be preserved as it was at the time, not recomputed under today's rates. Storing it means owning the refresh path and accepting that it can disagree with its inputs.
saying these in an interview costs you the question
- Calling something atomic or composite as if it were absolute, rather than relative to what the business needs to query
- Treating a multivalued attribute as fine to store as a comma-separated string
- Confusing multivalued (several values now) with historical (one value, many versions over time)
- Assuming a derived attribute must never be stored, so any materialised total is automatically wrong
- Describing derived attributes as ones the user does not see, rather than ones computable from other data