Hi Robert, I think what you're noticing is that every column in a SQL database is an attribute; i.e., it contains meaningful data of a certain type, which means that as graphs SQL schemas are very 'pointy'. To faithfully encode SQL foreign keys as edges requires adding additional edges and some path equalities.

For example, suppose we are given

CREATE TABLE Employee(id INT PRIMARY KEY, first VARCHAR(255), last VARCHAR(255), manager INT, worksIn INT
);

CREATE TABLE Department( id INT PRIMARY KEY,name VARCHAR(255), secretary INT,
);

ALTER TABLE Employee ADD CONSTRAINT e1 FOREIGN KEY (manager) REFERENCES Employee (id);

ALTER TABLE Employee ADD CONSTRAINT e2 FOREIGN KEY (worksIn) REFERENCES Department (id);

ALTER TABLE Department ADD CONSTRAINT d1 FOREIGN KEY (secretary) REFERENCES Employee (id);


the equivalent category presentation (i.e., the class of models of this presentation is isomorphic to the class of models of the SQL schema, provided the type sorts (INT, etc) are interpreted identically):

nodes
DEPARTMENT, VARCHAR, EMPLOYEE, INTEGER;
edges
DEPARTMENT__SECRETARY__EMPLOYEE_ID : DEPARTMENT -> EMPLOYEE,
SECRETARY : DEPARTMENT -> INTEGER,
ID : DEPARTMENT -> INTEGER,
NAME : DEPARTMENT -> VARCHAR,
EMPLOYEE__WORKSIN__DEPARTMENT_ID : EMPLOYEE -> DEPARTMENT,
EMPLOYEE__MANAGER__EMPLOYEE_ID : EMPLOYEE -> EMPLOYEE,
ID : EMPLOYEE -> INTEGER,
MANAGER : EMPLOYEE -> INTEGER,
WORKSIN : EMPLOYEE -> INTEGER,
LAST : EMPLOYEE -> VARCHAR,
FIRST : EMPLOYEE -> VARCHAR;
equations
WORKSIN = ID o EMPLOYEE__WORKSIN__DEPARTMENT_ID,
MANAGER = ID o EMPLOYEE__MANAGER__EMPLOYEE_ID,
SECRETARY = ID o DEPARTMENT__SECRETARY__EMPLOYEE_ID;