There is a visual language (see also this post) for databases, in the framework proposed by Evan & David et al., where a schema is a regular category. A data type A can be drawn as a string, and a predicate R on \Pi A_i can be drawn as a box with a list of strings.

In a database, R is a table in which each A_i is a column, and each row is a tuple (a_1,\dots, a_n) which satisfies R. This is generally the most popular way to organize data: the relation-based SQL is the most widely use database language.

Predicates are *bifibered* over sets, meaning that we can â€śpush and pullâ€ť along functions.

In a database, this gives two basic operations we can do on tables:

- we can
**push forward**along a function: f_!Q(\vec{a}) = \Sigma \vec{x}. Q(\vec{x})\land (f\vec{x}=\vec{a}),

- or we can
**substitute**along a function: R[f](\vec{x}) = R(f\vec{x}).

Together, these two constructions give the basic database operations:

**select**columns: push forward along projections, (see SQL Select)

**join**tables on a column: substitute along the diagonal. (see SQL Join)

(This was described by Michael Lambert here; now weâ€™re just showing its visual form.)

Composing these operations with other predicates, we can express the ubiquitous **select-from-where** query of SQL: the diagram below gives the table of tuples (a_i,\dots, a_j) satisfying \varphi which formed part of a row in R.

In particular, the predicate is often given by applying a function and then relating to some value of another data type, such as â€śemployee.salary > $100â€ť.

So in this visual language, we can express the standard data operations, and far more.

Once we create a **visual editor** for public use, people can use this intuitive interface to create schemas of their own, and explore the world in a new and fruitful way.