Whether you are designing a schema for an Android app or cramming for a database exam, attribute types come up early and keep coming back. The Crazy Programmer's walkthrough of DBMS concepts lays out eight flavours of attributes that appear again and again in entity-relationship diagrams and relational designs.
Knowing which is which keeps your tables clean, your queries fast and your data sane. Here is the same breakdown, rewritten for everyday use.
Key facts
- Complex attributes split into smaller pieces, like a full name broken into first, middle and last.
- Simple attributes cannot be split any further, such as age.
- Single-valued attributes hold one value, like a date of birth.
- Multivalued attributes hold several values, such as multiple degrees.
- Derived attributes are calculated from other attributes, such as age from birth date.
- Stored attributes are the values held in the database as-is.
- Key attributes uniquely identify an entity, like a student registration number.
- A combination of multivalued and complex, sometimes called nested, sits in the middle.
Simple vs complex
A simple attribute stays as one atomic value, no further split possible. Examples are age, height, or a yes/no flag. A complex attribute is itself a small group of related sub-parts, like a name made of first, middle and last, or an address made of street, city and postal code. The reference notes that parentheses are the usual way to show complex attributes on an ER diagram.
The practical rule of thumb: if you can imagine a sensible sub-field that also has meaning on its own, you are probably looking at a complex attribute.
Single-valued vs multivalued
Single-valued means one value per entity, always. A person's date of birth fits. Multivalued means more than one value is allowed for the same entity. The reference gives degrees as the classic example: a single person can hold both an undergraduate and a postgraduate degree. ER diagrams usually show multivalued attributes with double ovals.
Multivalued attributes are one of the first triggers for splitting a table. A relational database does not love storing several values in one column, so the usual fix is a new table with a foreign key back to the original entity.
Stored vs derived
Stored attributes sit in the database at their raw value. A birth date is a stored attribute. A derived attribute does not get stored directly; it is calculated when needed. Age is the textbook example: derive it from today's date and birth date instead of storing an age that has to be refreshed every year.
Deriving in code keeps data consistent and avoids update bugs, at the cost of a small computation on read.
Key attributes and the rest
A key attribute uniquely identifies an entity inside its set. Student registration numbers, vehicle chassis numbers and national ID numbers all fit. The value of a key attribute is unique, never null, and usually indexed for fast lookup. Keys are also where the relationships in a relational database hang, so getting them wrong ripples through the whole schema.
The reference also flags a hybrid sometimes called a complex-multivalued attribute, where a single value has multiple sub-parts that themselves come in groups. A person's degrees, each one split into title, institution and year, is the classic case. Modelling those usually means a separate table with several columns that captures every level.
Our analysis
For app developers, the cleanest mental move is to translate each attribute type into a storage decision. Simple and single-valued attributes drop into a single column. Multivalued and complex attributes usually want their own tables. Derived attributes usually belong in code, not in storage. Keys want indexes and tight validation.
Say you are building a contacts app for Android. A contact has a name, several phone numbers, several emails, and possibly a profile photo. The name is complex, so split it into first, middle, last columns or a small lookup. The phone numbers are multivalued, so they belong in a child table with a foreign key to the contact. The profile photo is stored as a reference, possibly a URL or a file path, not in the same table.
That kind of mapping is what stops a SQLite database from turning into a swamp of comma-separated strings within a year. It also keeps your queries joinable and your exports portable.
Bottom line
Treat attribute types as a design checklist. Simple or complex, single or multi, stored or derived, key or not. Run each field through the list and your tables will thank you later.
Frequently asked questions
What is the difference between a simple and a complex attribute?
A simple attribute cannot be split into smaller meaningful parts, while a complex attribute has its own sub-parts, like a full name into first, middle and last.
Why are multivalued attributes a problem in relational databases?
Storing several values in a single column breaks the rules of first normal form and complicates queries, so designers usually move them into a separate table.
Should derived attributes be stored?
Usually no. Derive them at read time from stored values to avoid stale data and update bugs.
What makes an attribute a key attribute?
It uniquely identifies each entity in its set, such as a registration number or a chassis number.
What is a nested or complex-multivalued attribute?
It is a multivalued attribute whose values are themselves complex, like several degrees, each split into title, institution and year.