Is a string always non-atomic because it contains characters?

No. A type system may treat a string as one atomic value while still offering character operations.

Are atomic and primitive types identical terms?

Not universally. A system may define derived atomic types, so consult its terminology.

Does an atomic field have to be non-null?

No. Nullability or optionality is a separate schema decision, subject to the system's rules.

AI Glossary / Data engineering and architecture / Beginner

Atomic data types

Definition

Atomic data types are types whose values are treated as individual units by a particular data model or type system, rather than as collections or records built from separately modeled components. Common introductory examples include integers, Boolean values and strings. The exact classification depends on the system and should not be confused with atomic transactions or atomic processor operations.

What it means

A type tells software what kind of value it is handling and which operations make sense. An integer can support arithmetic, a Boolean represents a truth value and a string represents text. An atomic value is handled as one value at the relevant modeling level.

Atomic does not mean physically indivisible. A string contains characters, and a date can have a year, month and day. A specification can still treat these as atomic values while providing functions that inspect their content.

The useful contrast is with a structured value such as a record containing several named fields, or a list containing several elements. A record may contain atomic fields, but that does not make the whole record an atomic type in the same type system.

How it works

A system defines a type's allowed values, representations and supported operations. A value may be accepted only if its representation and meaning satisfy the type's rules.

A schema then assigns types to fields or elements. Constraints can narrow a type further, such as requiring an integer count to be non-negative. The type and constraint play related but different roles: being an integer does not by itself establish that a quantity is valid for a particular business process.

W3C XML Schema explicitly distinguishes atomic, list and union datatypes. Its terminology belongs to that specification; it should not be assumed to match every programming language or database exactly. PostgreSQL, for example, documents both ordinary scalar types and composite or array structures.

Type conversion requires care. Converting text to a number can discard formatting that matters to an identifier, while a failed conversion needs an explicit handling policy.

Three practical examples

An inventory system stores a count as an integer and applies a separate rule that the accepted count cannot be negative.
A form stores a yes-or-no response as a Boolean when the application has defined how an unanswered question is represented.
A data exchange schema represents a single date as one typed value and validates incoming date representations before accepting them.

Think of it this way

Think of labeled containers at a service counter: one for a whole-number count, one for a yes-or-no response and one for a piece of text. The label tells the service how to interpret what is supplied.

The analogy is limited because a value can have an internal representation even when the model treats it as one unit. A sealed text container may contain many characters. Atomic describes the model's treatment of the value.

Worked example

A code is not necessarily a number

An invented delivery dataset contains a customer code written as 0072 and a parcel count written as 12. The count represents a quantity: adding one parcel should change it to 13. The customer code identifies an account and does not support meaningful arithmetic.

If the code is converted to integer 72, the leading zeros disappear from its ordinary representation. That may break comparison with another system that treats 0072 as the required four-character identifier. A string with a four-digit format constraint can preserve the intended representation.

Both are single values, but their types and validation differ.

Now suppose one source writes two customer codes into a field as 0072,0091. Storing that text as a string does not answer the modeling question of whether the field is meant to hold one identifier or a collection. That decision belongs in the schema and data contract.

Illustrative case study

A fictional support platform asks an AI assistant to propose a schema for imported survey responses. The assistant initially maps an unanswered yes-or-no question to false. The resulting reports treat people who skipped the question as people who explicitly answered no.

The team separates the Boolean response from the representation of missing information. It documents whether absence is allowed and tests all three cases: yes, no and unanswered. It also distinguishes a false value from a failed attempt to parse the source text.

The case shows that choosing an atomic type is only part of modeling. Missingness, validation and interpretation still determine whether downstream analysis describes what respondents actually supplied.

Common misconceptions and mistakes

Atomic means the value has no internal parts at any level. Atomicity is relative to a model; strings and dates illustrate the distinction.
Every value that looks numeric should use a numeric type. Identifiers can have formatting and equality rules that arithmetic types do not preserve.
An atomic datatype guarantees an indivisible update. Transactional and concurrency atomicity are separate concepts.

Business use

Atomic types provide the building blocks for data contracts, database columns and exchanged messages. Typing clarifies comparison, calculation and validation.

For an AI project, agree on field meaning before automating ingestion. Decide which fields are quantities, identifiers, dates or categories. Specify acceptable ranges, missing-value conventions and conversion failures. Review examples from real source systems, including leading zeros, blank strings and unexpected symbols.

Avoid treating a successful parse as proof of business correctness. A date may be valid but refer to the wrong event; an integer may exceed the allowed inventory capacity. Pair type checks with domain rules and retain enough source context to investigate errors.

Check your understanding

Why might an account code 0038 be stored as text while an item count 38 is stored as an integer?

Answer: The account code is an identifier whose representation can matter; the count is a quantity used in arithmetic. Their similar appearance does not give them the same meaning.

Related terms

Data type
Array
Schema
Domain Constraint
Data Contract
scalar value
composite type
type conversion
null

Learn next

Read scalar and composite types. Choose five fields from a form and specify each field's meaning, type, allowed values and missing-value policy before proposing a database column.

Sources

W3C, XML Schema Definition Language 1.1 Part 2: Datatypes: https://www.w3.org/TR/xmlschema11-2/. Primary specification defining atomic values and distinguishing type varieties.

PostgreSQL, Data Types: https://www.postgresql.org/docs/current/datatype.html. Primary overview of supported value types.

PostgreSQL, Composite Types: https://www.postgresql.org/docs/current/rowtypes.html. Primary documentation of structured record values. The delivery and survey cases are original illustrations.

Previous: Atom Next: Atomic representation