An entity in your model has an attribute that can hold several values at once, such as a customer's phone numbers. How is that mapped to relational tables, and why not use repeated columns or one comma-separated string?

## The rule A multivalued attribute is one that holds a set of values for a single entity instance at the same time: phone numbers, email addresses, tags, skills. The relational model has no place to put a set inside a single value, so the mapping algorithm gives every multivalued attribute its own table. That table contains the owner's primary key plus one column per value component. Its primary key is the owner key together with the value, and the owner key is a foreign key to the parent table. Reading the owner's values is a single lookup by owner key. ## Why not repeated columns phone1, phone2, phone3 is called a repeating group and it is the shape normalisation exists to remove. The problems are practical: - The maximum is baked into the schema, and the fourth value requires a migration. - One logical fact lives in several columns, so "find the customer with this number" has to test each column, and adding a column silently breaks every such query. - Constraints and uniqueness cannot be stated once; they have to be repeated per column, and across columns they cannot easily be stated at all. - Most rows waste the unused columns, and there is no meaningful order or identity to the slots. ## Why not a delimited string Storing "555-1234,555-9876" in a single column looks compact and fails on everything the database is for. The values are not individually typed, so nothing stops a malformed entry. They cannot be foreign keys, so referencing another table is impossible. Uniqueness per value cannot be enforced. Lookups become substring matches, which are both inefficient and wrong — searching for 555-123 matches 555-1234. Adding or removing one value requires reading, parsing, editing and rewriting the whole string, which is also a concurrency hazard when two writers do it at once. ## The child table in practice Beyond correctness, the child table is the design that keeps its options open. Two extensions arrive almost every time: **Each value gains attributes.** A phone number acquires a type, a verified timestamp, a preferred flag. In a child table these are new columns. In a delimited string they are impossible without encoding structure inside the text. **The values become shared.** If the values start referring to something the business manages separately — skills from a controlled vocabulary, tags from a tag catalogue — the child table turns into a junction table by replacing the value column with a foreign key. That is a small change from a child table and a rewrite from a string column. At that point the multivalued attribute has effectively become an entity, which is the same continuum described in the conceptual model: bare set of values, then values with their own facts, then a full entity. ## Ordering and duplicates Two questions are worth asking explicitly during the mapping. Does the order of the values carry meaning? If it does, add an explicit sequence column rather than relying on insertion order, because a table has no inherent row order. Are duplicate values legitimate for one owner? Usually not, which is why the owner-plus-value primary key is a good default — but if they are, the key needs another component. ## The honest exception Modern engines offer array and document column types, and they are occasionally the right call for a small, private, unshared, unqueried, unconstrained list. Even then the tradeoff is real: you give up per-value constraints and referential integrity, and you inherit whatever query syntax that type imposes. The default remains a child table, and "I would use a child table unless the list is small, private and never searched" is a stronger answer than either dogma.