DataslopeAttributes and Their Domains
Learn how entity properties become columns, and how domains define the allowed values for those columns.
Once you have an entity like customer, the next question is: what
facts do we need to remember about each customer? Those facts are
attributes.
Attributes become columns. But good columns are not just names — they also have domains, the set of values that are allowed to appear.
Attributes describe an entity
An attribute is a property of an entity. A customer might have a name, email address, signup date, and loyalty status. An order might have an order date, status, and total amount.
In a table, each attribute usually becomes one column. Each row then stores the values for one real entity.
Domains say what values are allowed
A domain is the set of valid values for an attribute. In SQL, the
domain is partly expressed by the column's data type and partly by
rules such as NOT NULL, CHECK, and UNIQUE.
The point is not just neatness. A narrow domain protects meaning. If
status can contain anything, your application must guess what
sent, shipped, SHIP, and done mean.
A good design lets PostgreSQL reject values that do not belong. That makes bad data harder to create in the first place.
Atomic values: one value per cell
A column should usually hold one value, not a list packed into a single cell. This is called atomicity. It is the core idea behind first normal form, which we will study later.
A phone_numbers value like '555-1111, 555-2222' may look simple,
but it hides multiple facts in one cell. If you later need to verify,
label, or delete one phone number, the design fights you.
Quick check
What does a column's domain describe?
The table where the column appears.
The set of valid values for that attribute, often enforced by types and constraints.
The number of rows currently in the table.
The order in which columns are displayed.
Attribute or its own entity?
Some facts are simple properties. Others deserve their own table. The question is not "is it a noun?" but "does this thing have its own identity, attributes, or relationships?"
For example, customer.email is often a simple attribute. But
address might become an entity if a customer can have many addresses,
if orders ship to saved addresses, or if addresses need their own
validation and history.
Do not model everything as a separate table
A table has a cost: keys, relationships, joins, and rules. Make a new entity when the thing has independent meaning, repeated instances, or relationships of its own — not just because it is a noun.
Attributes should be named for meaning
Good attribute names describe what the value means. created_at is
clearer than date. total_cents is clearer than amount when the
unit matters.
The name, type, and constraints work together. A column called
total_cents with type INTEGER and a nonnegative check is much
harder to misunderstand.
Check your understanding
What is an attribute of an entity?
A database backup of that entity.
A property or fact about the entity, such as a customer's email address.
A relationship between two unrelated tables.
The SQL command used to query the table.
Why is storing red, blue, green in one colors cell usually a design smell?
Because text columns cannot store commas.
Because the cell contains a list instead of one atomic value.
Because colors must always be stored as numbers.
Because PostgreSQL cannot read strings with spaces.
When is a concept more likely to become its own entity instead of just an attribute?
When it is spelled with more than five letters.
When it appears near the top of a form.
When it has its own details, repeated instances, or relationships to other entities.
Whenever it is stored as text.