Category Theory
Zulip Server
Archive

You're reading the public-facing archive of the Category Theory Zulip server.
To join the server you need an invite. Anybody can get an invite by contacting Matteo Capucci at name dot surname at gmail dot com.
For all things related to this archive refer to the same person.

Stream: theory: applied category theory

Topic: Primary Keys in Ologs

Julius Hamilton (Jan 18 2025 at 21:57):

This is a schema:

schema-a

In SQL, we can write:

CREATE TABLE Human (
    name TEXT PRIMARY KEY,
    mom TEXT,
    FOREIGN KEY (mom) REFERENCES Human(name)
);

When I look at the olog, I would like to say that "mom" is a morphism from Human to Human, such that mom(h), $h \in \text{Human}$ is h's mom. So the codomain of mom is Human.

In SQL, "Human" would not be an acceptable data type:

CREATE TABLE Human (
    name TEXT PRIMARY KEY,
    mom HUMAN,
);

and as I understand it, we use primary keys as a way to refer to an entity that a row of a table represents. Instead of referring to a mom in general, we refer to them by their name. Thus, name becomes a primary key for the table, and the data type of attribute mom is TEXT.

In the olog format, I think this means my diagram is wrong. Actually, the morphism mom is from Human to Text. It denotes the name of a person's mom:

schema-b

I feel like this means that in the olog, we can compose the morphism name with mom: Human -> Human, to get a morphism mom_name: Human -> Text.

schema-c.png

I feel like what stands out here is that in the olog, we would be more inclined to denote the morphism mom and name, and let the morphism mom_name be implicit. But in SQL, we make the morphisms name and mom_name explicit, and the 'foreign key' keyword implies there is a morphism mom : Human -> Human with the equation name(mom(h)) = mom_name(h).

schema-d

Would anyone like to comment on this?

Ryan Wisnesky (Jan 19 2025 at 00:24):

As far as I am aware, primary keys (even unary ones) in schemas are not possible in the original, purely equational functional olog formalism (functors to Set). You need more than equational logic: you need cartesian logic / pullbacks : "forall x y : Person, x.name = y.name -> x = y" states that name is a key of Person. David talks about this in "Database queries and constraints as lifting problems" and this is why CQL's "constraints" rather than "schemas" are the main abstraction. For functors into Rel, the story is different - there, I think you can express primary keys as equations. Evan Patterson would know more about the Rel story presumably.

Julius Hamilton (Jan 19 2025 at 01:28):

Amazing thank you