The connection between FQL and SQL (or rather, SPCU+keygen relational algebra) is described in 'Relational Foundations for Functorial Data Migration': http://arxiv.org/abs/1212.5303. Given a directed multi graph, the simplest strategy is to have one reflexive two column table for each node and one two column table representing a total function for each edge. FQL emits this SQL:


CREATE TABLE Germans(c0 VARCHAR(255) PRIMARY KEY, c1 VARCHAR(255));
CREATE TABLE Italians(c0 VARCHAR(255) PRIMARY KEY, c1 VARCHAR(255));
CREATE TABLE friendOf(c0 VARCHAR(255) PRIMARY KEY, c1 VARCHAR(255));
CREATE TABLE friendOf2(c0 VARCHAR(255) PRIMARY KEY, c1 VARCHAR(255));

But Matthew is correct that you can (and probably should) add foreign key indicators as well (these are just tricky to do in SQL when there are cycles). If instead of SQL we permit ourselves first-order logic (or rather, so-called 'embedded dependencies'), we can completely axiomatize the instances we want (also taken from FQL):


forall v0 v1, Germans(v0, v1) -> v0 = v1
forall v2 v3, Italians(v2, v3) -> v2 = v3
forall v4 v5, friendOf(v4, v5) -> Italians(v5, v5) /\ Germans(v4, v4)
forall v4 v5 v6, friendOf(v4, v6) /\ friendOf(v4, v5) -> v5 = v6
forall v6, Germans(v6, v6) -> exists v7, friendOf(v6, v7)
forall v8 v9, friendOf2(v8, v9) -> Italians(v8, v8) /\ Germans(v9, v9)
forall v8 v9 v10, friendOf2(v8, v9) /\ friendOf2(v8, v10) -> v9 = v10
forall v10, Italians(v10, v10) -> exists v11, friendOf2(v10, v11)

Of course, you could instead 'pre join' all the binary tables together (often done in papers to save space), or use unary tables for the nodes, and other techniques.