Table of Contents
Fetching ...

How to get Rid of SQL, Relational Algebra, the Relational Model, ERM, and ORMs in a Single Paper -- A Thought Experiment

Jens Dittrich

TL;DR

This work introduces the Relational Map Type Model (RMTM) as a unifying data representation that subsumes RM and ERM while addressing their limitations. It replaces traditional query languages with Map Views, a functional, map-based abstraction that operates on nested maps at arbitrary granularity, enabling outputs beyond a single relation (e.g., databases and sets of databases). The authors present seven requirements for an RMTM QL, demonstrate how direct pointer navigation (swizzling) can outperform conventional joins, and provide experimental evidence of up to 3× speedups in star-join scenarios. They further argue for abandoning SQL, RA, RM, ERM, and ORMs in favor of map views, asserting security, integration with host programming languages, and simplified schema management. The work outlines a practical path toward a universal, non-textual data language tightly coupled with the PL and DBMS, with broad implications for database architecture and software engineering.

Abstract

Without any doubt, the relational paradigm has been a huge success. At the same time, we believe that the time is ripe to rethink how database systems could look like if we designed them from scratch. Would we really end up with the same abstractions and techniques that are prevalent today? This paper explores that space. We discuss the various issues with both the relational model(RM) and the entity-relationship model (ERM). We provide a unified data model: the relational map type model (RMTM) which can represent both RM and ERM as special cases and overcomes all of their problems. We proceed to identify seven rules that an RMTM query language (QL) must fulfill and provide a foundation of a language fulfilling all seven rules. Our QL operates on maps which may represent tuples, relations, databases or sets of databases. Like that we dramatically expand the existing operational abstractions found in SQL and relational algebra (RA) which only operate on relations/tables. In fact, RA is just a special case of our much more generic approach. This work has far-reaching consequences: we show a path how to come up with a modern QL that solves (almost if not) all problems of SQL. Our QL is much more expressive than SQL and integrates smoothly into existing programming languages (PL). We also show results of an initial experiment showcasing that just by switching to our data model, and without changing the underlying query processing algorithms, we can achieve speed-ups of up to a factor 3. We will conclude that, if we build a database system from scratch, we could and should do this without SQL, RA, RM, ERM, and ORMs.

How to get Rid of SQL, Relational Algebra, the Relational Model, ERM, and ORMs in a Single Paper -- A Thought Experiment

TL;DR

This work introduces the Relational Map Type Model (RMTM) as a unifying data representation that subsumes RM and ERM while addressing their limitations. It replaces traditional query languages with Map Views, a functional, map-based abstraction that operates on nested maps at arbitrary granularity, enabling outputs beyond a single relation (e.g., databases and sets of databases). The authors present seven requirements for an RMTM QL, demonstrate how direct pointer navigation (swizzling) can outperform conventional joins, and provide experimental evidence of up to 3× speedups in star-join scenarios. They further argue for abandoning SQL, RA, RM, ERM, and ORMs in favor of map views, asserting security, integration with host programming languages, and simplified schema management. The work outlines a practical path toward a universal, non-textual data language tightly coupled with the PL and DBMS, with broad implications for database architecture and software engineering.

Abstract

Without any doubt, the relational paradigm has been a huge success. At the same time, we believe that the time is ripe to rethink how database systems could look like if we designed them from scratch. Would we really end up with the same abstractions and techniques that are prevalent today? This paper explores that space. We discuss the various issues with both the relational model(RM) and the entity-relationship model (ERM). We provide a unified data model: the relational map type model (RMTM) which can represent both RM and ERM as special cases and overcomes all of their problems. We proceed to identify seven rules that an RMTM query language (QL) must fulfill and provide a foundation of a language fulfilling all seven rules. Our QL operates on maps which may represent tuples, relations, databases or sets of databases. Like that we dramatically expand the existing operational abstractions found in SQL and relational algebra (RA) which only operate on relations/tables. In fact, RA is just a special case of our much more generic approach. This work has far-reaching consequences: we show a path how to come up with a modern QL that solves (almost if not) all problems of SQL. Our QL is much more expressive than SQL and integrates smoothly into existing programming languages (PL). We also show results of an initial experiment showcasing that just by switching to our data model, and without changing the underlying query processing algorithms, we can achieve speed-ups of up to a factor 3. We will conclude that, if we build a database system from scratch, we could and should do this without SQL, RA, RM, ERM, and ORMs.

Paper Structure

This paper contains 23 sections, 1 theorem, 5 equations, 4 figures, 1 table.

Key Result

Corollary 1

A DB is a map. Therefore, a DB is also an enumeration (recall def:mapenum).

Figures (4)

  • Figure 1: Running Example ERM
  • Figure 2: An entity types with attributes and an underlined key attribute vs a relationship type with three entity types and (min,max)-functionalities, one of them a (1,1)-functionality
  • Figure 3: Differences of RM vs RMTM
  • Figure 4: Results of a star join on a fact table with 50 million tuples varying the number of dimension tables: RM vs RMTM

Theorems & Definitions (37)

  • Definition 1: Instance
  • Definition 2: Key
  • Definition 3: Value
  • Definition 4: Assignment
  • Definition 5: Exclusive Assignment
  • Definition 6: Non-Exclusive Assignment
  • Definition 7: Map
  • Definition 8: Map Type (MT)
  • Definition 9: Relational Map Type (RMT or Tuple Type)
  • Definition 10: Optional and Mandatory Keys
  • ...and 27 more