Theory
Three details, three problems
Meera's customer record has three tricky details:
- a customer number that must never repeat,
- an age, which changes every birthday,
- and a customer who has given three phone numbers.
Each is an attribute, but each behaves differently, and handling them wrong causes real bugs: duplicate customers, wrong ages, phone numbers that will not fit. Attributes come in types, and knowing them is how you avoid these traps. Two of these types are also early warnings of a design that needs fixing.
At a glance
Attribute types
| Type | Meaning | E/R symbol |
|---|---|---|
| Key | Uniquely identifies a record | Underlined ellipse |
| Derived | Computed from others (age) | Dashed ellipse |
| Multi-valued | Holds several values (phones) | Double ellipse |
| Composite | Splits into parts (address) | Ellipse with sub-ellipses |
Theory
The three that matter most
- Key attribute: uniquely identifies each record,
customer_id. No two customers share it. Shown underlined. - Derived attribute: its value can be calculated from others,
agefromdate_of_birth,totalfromprice x quantity. You should not store it; compute it when needed. Shown as a dashed ellipse. - Multi-valued attribute: holds more than one value for one entity, a customer's several phone numbers. Shown as a double ellipse. It is a red flag: it does not fit in a single column cleanly.
Quiz
Meera stores each customer's 'age' as a fixed number in the table. Why is this a bad idea?
- Age is a derived attribute; it should be computed from date of birth, not stored, or it goes stale
- Age takes up too much storage space
- Age cannot be a number in a database
- Ages must always be stored as text
Show the answer
Age is a derived attribute; it should be computed from date of birth, not stored, or it goes stale
Age is derived from date of birth and changes every year, so a stored age is wrong the day after the next birthday unless someone updates it. Store the stable date_of_birth and compute age on demand. Storing derived values is a classic source of stale, inconsistent data, which is exactly why derived attributes are drawn with a dashed ellipse and kept out of storage.
Think first
The three phone numbers problem
A customer gives three phone numbers. Meera is tempted to cram them into one 'phone' cell as '9876..., 9123..., 9000...'. Why is a multi-valued attribute a design warning, and what is the correct fix?
Show the answer
Cramming multiple values into one cell breaks the rule that each cell holds one value (first normal form). You cannot search or count them properly, exactly the 'name, phone in one column' mess from Unit 2. The fix: give phone numbers their own separate table (customer_id + phone_number, one row per phone). A multi-valued attribute is nature's way of telling you a new table is needed, the seed of normalization.
Watch out
Where marks leak
Storing derived attributes (age, totals), compute them, do not store them (they go stale). Cramming a multi-valued attribute into one cell, it needs a separate table. Mixing up the E/R symbols: key = underlined, derived = dashed ellipse, multi-valued = double ellipse, composite = ellipse with sub-parts. And a composite attribute (address = street + city + pincode) should be split into its atomic parts. These symbol-and-purpose pairings are standard exam marks.
Theory
You just previewed normalization
Two attribute types, multi-valued and composite, are literally the problems that first normal form exists to fix. You have met the disease before the cure has a name. And the key attribute is about to expand into a whole family of keys in the next lesson. Attribute types are the vocabulary; keys and normalization are where they pay off. Next: the full family of keys.
Summary
Key takeaways
- Key attribute: uniquely identifies each record (customer_id); shown underlined.
- Derived attribute: computed from others (age from DOB); do NOT store it, or it goes stale; dashed ellipse.
- Multi-valued attribute: holds several values (many phones); double ellipse; needs a separate table.
- Composite attribute: splits into parts (address = street+city+pincode).
- Multi-valued and composite attributes are exactly what first normal form fixes.
- Memory hook: key identifies, derived is calculated (never stored), multi-valued means a new table.