Is elementary domain a universally standardized product term?

No. Usage depends on the modeling text or system, so the intended meaning should be stated.

Does a basic type define every valid business value?

No. Additional constraints and context usually matter.

Are strings non-elementary because they contain characters?

Not necessarily. A model can treat a string as a single scalar value while still providing string operations; the classification depends on the formalism.

AI Glossary / Data engineering and architecture / Intermediate

Elementary Domain

Definition

Elementary domain is a database-modeling term for a basic value domain, such as numbers, character strings, or dates, used as a building block for attributes. The label is not uniformly used across modern database products. In introductory relational and historical SQL discussions, it contrasts basic attribute values with more elaborate constructed structures. This entry uses that limited sense and does not imply that current SQL systems support only elementary types.

What it means

When defining a field, a designer first decides what kind of value it holds. An integer count, a text identifier, and a date support different operations and interpretations. A basic domain supplies this foundation, while additional constraints can narrow the permitted values. The distinction is useful for modeling, but “basic” does not mean that the business meaning is fully specified. Two integer fields can represent completely different quantities.

How it works

Select a value category appropriate to the attribute, then specify relevant size, precision, range, and missing-value rules. A database type implements some of these choices, and constraints can add domain-specific restrictions. Use operations appropriate to the chosen type. Modern systems also offer arrays, composite types, documents, and user-defined types, so the elementary-domain concept should be read in its modeling context rather than as a universal catalog of supported features. Atomicity is relative to the chosen model and operations.

Three practical examples

Registration data: a seat count uses an integer representation with a nonnegative constraint, while a registration code remains text even when it contains only digits.
Event scheduling: a calendar date is stored with an appropriate date type rather than as an ambiguously formatted string, while time-zone requirements are considered separately for timestamps.
AI datasets: a class label, numeric measurement, and free-text explanation receive distinct representations so preprocessing does not treat all values as interchangeable strings.

Think of it this way

Think of choosing the basic kinds of containers in a workshop: one for measured quantities, one for labels, and one for calendar entries. The choice influences how contents can be handled. The analogy is limited because database domains define sets of values and operations, not just storage boxes. A character string may be treated as one value even though people can see individual characters inside it.

Worked example

A toy table needs fields for participant_code, completed_lessons, and enrollment_date. The code “00127” is an identifier, so a text representation preserves the leading zeros. completed_lessons is a count and can use an integer with a rule requiring values at least zero. enrollment_date uses a date representation with a clearly defined input convention. Converting all three fields to integers would lose the code's format and fail to represent the date meaningfully. Storing all three as unrestricted text would preserve characters but leave more validation and interpretation work to applications. The domain choice should follow meaning, not merely the appearance of the current sample values.

Illustrative case study

Fictional example: Fir Catalog imports item codes that happen to contain digits. A spreadsheet tool converts them to numbers and removes leading zeros. The database team clarifies that these are labels, not quantities, and chooses a text-based domain with an appropriate format rule. It separately defines numeric domains for dimensions and counts. This invented scenario illustrates modeling choices, not a claim that every numeric-looking identifier requires the same length or validation pattern.

Common misconceptions and mistakes

Do not assume an elementary domain is identical to a SQL DOMAIN declaration. The latter is a particular schema feature in supporting systems. Do not claim that modern relational products forbid structured types merely because older teaching material emphasizes basic domains. Avoid confusing physical representation with business meaning. A decimal type can represent money, weight, or a ratio, and each requires additional context. Also distinguish a missing value policy from the basic value category.

Business use

The practical use of this term is to encourage deliberate attribute design. When reviewing a schema, ask whether values are quantities, labels, dates, flags, or another concept, and choose a representation accordingly. Document units and constraints beside the type. For AI preparation, preserve identifiers and category codes during conversion so they do not accidentally become numerical features. The word “elementary” should help explain the foundation of a model, not obscure current product capabilities.

Check your understanding

An account code contains only digits and begins with two zeros. Should it automatically be modeled as an integer?

Answer: No. If it is a label rather than a quantity, a text domain may preserve its intended identity and formatting. Choose the domain from the concept, not just the visible characters.

Related terms

Data domain
Data type
Domain Constraint
First normal form (1NF)
scalar type
structured type
first normal form
identifier

Learn next

classify ten fields from a harmless sample dataset by meaning before choosing SQL types. For each, state permitted values, units or code conventions, and missing-value treatment. Compare those decisions with the actual database's supported types and constraints.

Sources

Primary implementation sources consulted: PostgreSQL Data Types, https://www.postgresql.org/docs/current/datatype.html; Numeric Types, https://www.postgresql.org/docs/18/datatype-numeric.html; Date/Time Types, https://www.postgresql.org/docs/18/datatype-datetime.html — excerpts consulted. These ground the type examples, not a universal definition of “elementary domain.” University of Toronto CSC343 SQL DDL teaching slides, https://www.cs.toronto.edu/~faye/343/w08/lectures/wk2/02a_SQL-DDL2-up.pdf, explicitly distinguish elementary domains from user-defined domains and illustrate character and numeric types. Examples are original; full editorial review remains pending.

Previous: Electronic seal Next: Elementary matrix