Database editing is made of natural transformations! Let's have a schema \\( \mathcal{C} \\)

\\[ \mathcal{C}: Record \rightarrow Integer \\]

for a very simple database type. Lets make instances over Set so we can have each integer exactly once in it. Here's one with 1 in it:

\\[ Gr(F) = \\{1\\} \\]

Gr stands for Grothendieck and I'm using it to show off, but it simply meas that I want to talk about F's elements. Really, I wouldn't know what else to call it. Slightly more interestingly I've decided that specifying the elements says everything about databases of the \\( \mathcal{C} \\) kind. Let's have another one with another element 2 in it:

\\[ Gr(G) = \\{1,2\\} \\]

Then we can relate the two databases F and G using a natural transformation called insert(2):

\\[ insert(2): F \rightarrow G \\]

or using an arrow pointing the other way called delete(2):

\\[ delete(2): F \leftarrow G \\]

Let's only call those natural transformations database editing that don't change the schema. Then we'd have to check that this square commutes:

& id & \\\\
\mathcal{C} & \longrightarrow & \mathcal{C} \\\\
F \downarrow & & \downarrow G \\\\
Gr(F) & \longrightarrow & Gr(G) \\\\
& insert(2) & \\\\

Erm, we just defined that insert(2) is the name for how Gr(F) and Gr(G) are related, so of course it commutes! Then, by label symmetry, the opposite one for delete will also commute %-P

It's conceivable to compose insert and delete to implement an update operation, let's say we want to change G such that this H is the result:

\\[ Gr(H) = \\{1,3\\} \\]

The corresponding update has two parameters and it's type is a map from G to H:

\\[ update(2,3) : G \rightarrow H = delete(2) \circ insert(3) \\]

I should still read some stuff, maybe later. I'm sorry, Ryan.

**Puzzle rf43.1:** What's the "schema" for these database editing operations? What's the most general way to capture what insert does such that we can compare it against a similar description of what delete does.