Above, I had the curious idea to post about natural transformations for a database type which had no relations. Incidentally, in most SQL database engines, you have to explicitly represent relations using numbers (you'd better use numbers). So instead of directly relating employees to the department they work in, we'd have to assign a unique key to every department record, and mention that key in the employee record:

\\[

department: Employee \rightarrow Integer \\\\

primaryKey: Department \rightarrow Integer

\\]

This works if every employee is working in either zero or one appartment. Zero can happen because in these "relational" database engines (I'm picturing you folks starting to wonder why people call those databases "relational" in the first place) you can alternatively put the special value NULL into any field. That can be turned off, but it's the default behaviour.

The best way to implement m:n relations is to use an extra Relation table like this:

\\[

primaryKey: Employee \rightarrow Integer \\\\

primaryKey: Department \rightarrow Integer \\\\

employeeKey: Relation \rightarrow Integer \\\\

departmentKey: Relation \rightarrow Integer

\\]

You see, the schema graph isn't even connected!

Okay. So any natural transformation between functors over a category without any arrows is bound to be trivial. It is also the reason why the commutative square I came up with looks so different than the ones the other people talked about. I had no arrows in my database schema, so I couldn't talk about them!

All this lack of consistency implies that any categorical version of SQL (like FQL or AQL) cannot be isomorphic to SQL, as SQL has no real way to establish the constraints given by a schema category. Well, some dialects allow to declare the meaning of constructions like the ones I just gave, such that if you try to remove a department, the database will try to also remove the employees related to it (or the corresponding relations from the Relation table).

I'm glad that so many answers address John's puzzles directly, without tweaking them as much as I seem to be doing! Without them, my confusion might be a much more serious issue!

\\[

department: Employee \rightarrow Integer \\\\

primaryKey: Department \rightarrow Integer

\\]

This works if every employee is working in either zero or one appartment. Zero can happen because in these "relational" database engines (I'm picturing you folks starting to wonder why people call those databases "relational" in the first place) you can alternatively put the special value NULL into any field. That can be turned off, but it's the default behaviour.

The best way to implement m:n relations is to use an extra Relation table like this:

\\[

primaryKey: Employee \rightarrow Integer \\\\

primaryKey: Department \rightarrow Integer \\\\

employeeKey: Relation \rightarrow Integer \\\\

departmentKey: Relation \rightarrow Integer

\\]

You see, the schema graph isn't even connected!

Okay. So any natural transformation between functors over a category without any arrows is bound to be trivial. It is also the reason why the commutative square I came up with looks so different than the ones the other people talked about. I had no arrows in my database schema, so I couldn't talk about them!

All this lack of consistency implies that any categorical version of SQL (like FQL or AQL) cannot be isomorphic to SQL, as SQL has no real way to establish the constraints given by a schema category. Well, some dialects allow to declare the meaning of constructions like the ones I just gave, such that if you try to remove a department, the database will try to also remove the employees related to it (or the corresponding relations from the Relation table).

I'm glad that so many answers address John's puzzles directly, without tweaking them as much as I seem to be doing! Without them, my confusion might be a much more serious issue!