Functional Data Model (FDM)

• Functional Data Model (FDM) is a mathematical abstraction that treats tuples, relations, and databases as functions and higher-order functions.
• It dissolves traditional boundaries between stored and computed data by intrinsically expressing constraints and relationships through function signatures.
• It enables embedding a functional query language within host programming languages, unifying query and update operations in a single functional paradigm.

Functional Data Model (FDM) denotes, in the 2025 database proposal of “A Functional Data Model and Query Language is All You Need,” a mathematical data model in which everything that is normally treated as data is represented as a function: a tuple is a function, a relation is a higher-order function returning tuple-functions, a database is a higher-order function returning relation-functions, and a set of databases is again a function. On this basis, the associated Functional Query Language (FQL) is defined as an algebra of higher-order functions over data-functions, with the stated aim of removing the conceptual boundary between tuples, relations, databases, stored versus computed data, and query language versus programming language (Dittrich, 28 Jul 2025).

1. Formal definition and ontological commitments

The defining primitive of the model is the standard mathematical notion of function: $$\text{A function } f:X\to Y \text{ assigns to each element of } X \text{ exactly one element of } Y.$$ A higher-order function is one whose domain or codomain is itself a set of functions. FDM applies this abstraction uniformly at every level of data representation. The central claim is therefore not merely that some attributes may be functional, but that tuples, relations, databases, and relationships are all instances of the same underlying construct (Dittrich, 28 Jul 2025).

This uniformity has several direct consequences. First, the traditional boundary between tuples, relations, and databases disappears: they are functions at different levels. Second, the boundary between stored and computed data disappears: attribute values, tuples, relations, and even databases may be computed rather than statically stored. Third, constraints such as keys, foreign keys, uniqueness, and indexes are expressed through domains, codomains, and typing rather than being treated as external add-ons.

The proposal is explicitly positioned as a mathematical model rather than a concrete physical representation. The paper distinguishes the conceptual model from what it calls a separate “physiological design” step, where an FDM may be mapped to a relational, key-value, JSON, or other physical store. This separation is significant because it places FDM at the level of semantic abstraction rather than storage format.

Historically, the terms “Functional Data Model” and “Functional Query Language” appeared in the late 1970s and 1980s in work associated with Shipman, Buneman, Atkinson, Gray, and others. The 2025 proposal distinguishes itself from those earlier models by strictly treating tuples, relations, and databases all as functions, by insisting that the model is only mathematical, and by designing the query language to be embedded as programming-language functions rather than as a separate textual language (Dittrich, 28 Jul 2025).

2. Functional representation of tuples, relations, databases, and relationships

A tuple is modeled as a function from attribute names to attribute values. A canonical example is

$$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$

with lookup realized as function application, such as $t_1(\text{`foo'}) = 12$. The model explicitly allows computed tuple functions. For example,

$$t(attr:\text{string}) := \begin{cases} 42 \cdot t_1(\text{`foo'}), & \text{if } attr = \text{`bar'},\ t_1(attr), & \text{otherwise.} \end{cases}$$

Here the derived attribute bar is part of the same data model as stored attributes, rather than belonging to a separate layer of views or computed fields (Dittrich, 28 Jul 2025).

Tuple functions may also be higher-order. An attribute can return another tuple function or a relation function. The example

$$t_3(attr) := \{\text{`name'}:\text{`Bob'},\ \text{`foo'}: t_1\}$$

makes foo return a tuple function. The paper notes that this violates 1NF but is fully admissible in FDM. The absence of any 1NF requirement is foundational for the model’s treatment of nesting.

A relation is a higher-order function from key values to tuple functions. If

$R1(bar:\text{int}) := t_{\text{bar}},$

then $R1(1)=t_1$ and $R1(3)=t_3$, while inputs outside the domain are undefined. Domains may be constrained explicitly, for example by

$$R(bar:X)\ \text{where } X = \{1,3\} \cap \mathbb{N}^+$$

or by interval-and-predicate constraints such as

$$R(bar:X)\ \text{where } X = [7;12] \cap \mathbb{R}^+.$$

In this scheme, typing and integrity constraints are expressed directly in the function signature.

Uniqueness follows from ordinary function semantics. If a relation function is defined on foo,

$$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$0

then a uniqueness constraint on foo is implicit because each input can map to at most one tuple function. To admit duplicates, the codomain is lifted to sets of tuple functions. The paper interprets this as conceptually matching an index on a non-unique column in relational DBMSs, but makes it intrinsic to the model rather than a physical implementation detail.

Relations may be partially or fully computed. In the example

$$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$1

stored and generated tuples coexist under one relation function. Evaluations such as $$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$2 and $$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$3 illustrate the same point.

A database is a function from relation names to relation functions. The example $t_1(\text{`foo'}) = 12$4 shows that DB("Table1") returns R1. As with lower levels, database functions may also return computed relation functions.

FDM also models relationships as functions. Given $$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$4 functions $$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$5 with domains $$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$6, a relationship is represented as

$$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$7

and if $$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$8, the result is a relationship predicate. In the paper’s example, an ER-style schema with customers(cid), products(pid), and order(cid, pid) is modeled by relation functions for entities and a relationship function for order. Foreign-key semantics are obtained from shared domains rather than separate FK declarations. The paper further states that relationships can be defined between anything that is a function, including between a database and a relation, as in is_accessed(DB, users) (Dittrich, 28 Jul 2025).

3. FQL as a higher-order function algebra embedded in programming languages

An FQL operator is defined as a higher-order function

$$t_1(attr:\text{string}) := \{(\text{`name'}:\text{`Alice'}), (\text{`foo'}:12)\},$$9

where both input and output are FDM functions. The paper describes the FQL algebra as consisting of FDM functions as operands, FQL functions as operators, and rules for combining them through nested operators. Although FQL is given a functional reading, the evaluation order is not fixed by syntactic nesting; both declarative and functional interpretations are allowed, and the optimizer may reorder operations (Dittrich, 28 Jul 2025).

This definition sharply distinguishes FQL from classical relational algebra. Relational algebra operators such as $t_1(\text{`foo'}) = 12$0 are defined over relations and produce one relation. FQL operators can act on functions representing tuples, relations, databases, or sets of databases, and can return arbitrary functions rather than a single relation schema. The paper gives as examples a group operator producing a database of relation functions and a reduce_DB operator consuming a subdatabase.

A central design choice is that FQL is intended to be embedded into host programming languages. The host language syntax is described as the “costume” of the FQL operator. In the Python examples, all of the following are treated as conceptually the same FQL operator:

$t_1(\text{`foo'}) = 12$5

The paper emphasizes several consequences. FQL does not introduce its own separate textual language. Queries are ordinary function calls in the host programming language. The programming-language compiler or runtime may push down parts of the function composition into the DBMS. Because queries are not assembled as concatenated SQL fragments, SQL injection is said to be impossible “by design.” More broadly, the proposal states that “both QL and PL become the same thing,” so that the distinction between query language and programming language disappears at the conceptual level (Dittrich, 28 Jul 2025).

This embedding claim is also the basis for what the paper calls holistic optimization opportunities between compilers and databases. A plausible implication is that optimization is no longer confined to a DBMS algebra alone, but may span mixed database and host-language computation, provided the system can reason over the shared function representation.

4. Expressiveness, subdatabase operations, aggregation, and updates

The expressiveness claim rests on the assertion that, because everything is a function, FDM naturally supports nested data, hierarchies and graphs, and higher-order structures. The example $t_1(\text{`foo'}) = 12$6 makes attribute foo return a relation function R. The same query constructs are said to apply whether a component is a tuple, relation, or database (Dittrich, 28 Jul 2025).

FQL can operate over entire databases rather than only over relations. The paper’s example of building a subdatabase is

$t_1(\text{`foo'}) = 12$7

The resulting subdatabase can then be joined: $t_1(\text{`foo'}) = 12$8 The paper explicitly notes that such a join may be executed as arbitrary $t_1(\text{`foo'}) = 12$1-ary joins, and that the optimizer is not forced into a binary join tree.

Grouping and aggregation can similarly return multiple results or even databases of groups. A multi-step example is $t_1(\text{`foo'}) = 12$9 and a fused variant is $$t(attr:\text{string}) := \begin{cases} 42 \cdot t_1(\text{`foo'}), & \text{if } attr = \text{`bar'},\ t_1(attr), & \text{otherwise.} \end{cases}$$0 For grouping sets and rollups, the paper proposes distinct relation functions per grouping level rather than one relation padded with NULLs: $$t(attr:\text{string}) := \begin{cases} 42 \cdot t_1(\text{`foo'}), & \text{if } attr = \text{`bar'},\ t_1(attr), & \text{otherwise.} \end{cases}$$1

A distinctive feature of the model is that queries and updates are expressed in the same function algebra. The paper differentiates between out-of-place use, which yields a new function corresponding to a read-only view or a snapshot, and in-place use, where the resulting function replaces a function inside the FDM. Examples include

$t_1(\text{`foo'}) = 12$2

and

$t_1(\text{`foo'}) = 12$3

At the host-language level, tuple-level updates are ordinary assignments or deletions: $$t(attr:\text{string}) := \begin{cases} 42 \cdot t_1(\text{`foo'}), & \text{if } attr = \text{`bar'},\ t_1(attr), & \text{otherwise.} \end{cases}$$2 Transactions are expressed similarly: $$t(attr:\text{string}) := \begin{cases} 42 \cdot t_1(\text{`foo'}), & \text{if } attr = \text{`bar'},\ t_1(attr), & \text{otherwise.} \end{cases}$$3 The semantics is described as “transactional snapshot,” with snapshots configurable at transaction or statement granularity.

Set operations generalize to entire databases: $$t(attr:\text{string}) := \begin{cases} 42 \cdot t_1(\text{`foo'}), & \text{if } attr = \text{`bar'},\ t_1(attr), & \text{otherwise.} \end{cases}$$4 This extends UNION, INTERSECT, and related ideas from relations to full database snapshots (Dittrich, 28 Jul 2025).

5. Claimed resolution of SQL and relational-model pathologies

The proposal explicitly aims to solve “(almost if not) all problems of SQL,” naming NULL-values, impedance mismatch, SQL injection, and missing querying capabilities for updates. Its treatment of NULL is not presented as a full formal replacement for SQL’s three-valued logic, but several design directions are specified. Missing attributes or absent mappings are handled as partial functions or domain constraints rather than as special null markers. Multi-semantics outputs, such as grouping sets or outer joins, are represented as separate functions or relations rather than as a single relation padded with NULLs (Dittrich, 28 Jul 2025).

For outer joins, the example is: $$t(attr:\text{string}) := \begin{cases} 42 \cdot t_1(\text{`foo'}), & \text{if } attr = \text{`bar'},\ t_1(attr), & \text{otherwise.} \end{cases}$$5 The paper’s point is that inner and outer parts are separated as distinct relation functions, so NULL is not used to encode heterogeneous row semantics.

Impedance mismatch is addressed through language embedding. Because FQL consists of typed functions in the host language, there is no special query language embedded through strings, and types are taken from the host language’s own type system, such as Python type hints or Rust types. The paper presents this as removing the classical mismatch that led to ORMs: one does not map between objects and rows, but works directly with functions that behave like structured language-level objects.

SQL injection is treated as a consequence of the separate textual SQL layer. Since predicates and queries are structured programming-language code or structured predicate-plus-parameter objects rather than concatenated SQL fragments, the proposal states that SQL injection is impossible “by design.” Even in the string-predicate variant, parameters are not concatenated into SQL but may be treated as typed values distinct from the predicate template.

The paper also contrasts SQL’s relatively powerful SELECT with weaker INSERT, UPDATE, and DELETE, arguing that SQL update operations are limited to tuple-level effects within one relation and have restricted interaction with views. FQL instead uses one compositional function algebra for both reading and writing. Transformations over whole relations or entire databases are therefore described in the same style as queries.

These claims are programmatic rather than experimentally validated. This suggests that the proposal should be read as a conceptual unification of data modeling, querying, and transformation, not as a completed implementation benchmark. The paper itself states that it is a vision piece and does not provide a formal cost model, a detailed optimizer, or a complete language specification (Dittrich, 28 Jul 2025).

6. Terminological ambiguity, related models, and open questions

The acronym “FDM” is substantially overloaded in contemporary technical literature. In the database paper, it means Functional Data Model (Dittrich, 28 Jul 2025). In structural form-finding, “JAX FDM” uses FDM to mean the Force Density Method of Schek (1974), implemented as a differentiable forward solver for inverse form-finding (Pastrana et al., 2023). In high-dimensional functional statistics, “functional data model” can refer to a factor-augmented smoothing model in which observed curves are modeled as a smooth function plus a high-dimensional factor component (Gao et al., 2021); closely related terminology appears again in “Factor-augmented model for functional data” (Gao et al., 2022). In asymptotic statistics, “FDM” may mean the Functional Delta Method, including the modified version based on quasi-Hadamard differentiability and weighted empirical processes (Beutner et al., 2012).

Usage of “FDM”	Meaning	Example paper
Database theory	Functional Data Model	(Dittrich, 28 Jul 2025)
Structural mechanics	Force Density Method	(Pastrana et al., 2023)
Functional statistics	Functional data model / factor-augmented smoothing model	(Gao et al., 2021)
Asymptotic statistics	Functional Delta Method	(Beutner et al., 2012)

Within database theory, the 2025 proposal positions itself relative to several neighboring models. It is said to differ from earlier functional data models of the 1970s and 1980s, to contrast with Rel by discarding the set-of-tuples abstraction in favor of functions throughout, and to diverge from SQL++ and JSON-relational duality by unifying everything under functions rather than by mixing model and syntax. It is also contrasted with ER-based query languages from the 1980s, which are described as less expressive because FDM can define relationships between arbitrary functions, including database-to-relation relationships. ORM-based approaches are described as retaining SQL and programming languages as separate worlds, whereas FDM/FQL attempts to collapse them into a single abstraction (Dittrich, 28 Jul 2025).

The paper also states several limitations and open questions. It provides no full language specification for FQL; operators are illustrated through examples rather than formally enumerated. It gives no formal type system beyond reusing host programming-language types together with domain and codomain constraints. It does not establish complexity bounds or an expressiveness classification relative to relational algebra, Datalog, or monad comprehensions. No implementation or optimizer is detailed, and the treatment of missingness, partiality, and NULL semantics is incomplete. The author identifies future work as including a full implementation of FQL and programming-language integration, exploration of the joint optimization space, and extension of the repertoire of FQL operators beyond SQL (Dittrich, 28 Jul 2025).

Taken together, these features define the Functional Data Model, in the 2025 sense, as a mathematically uniform, function-centric alternative to the relational model in which tuples, relations, databases, constraints, relationships, queries, and updates are all expressed through higher-order functions. The proposal’s importance lies less in a finished system than in the claim that a database model, a query language, and a host programming language can be collapsed into one typed functional abstraction.