Keith #16 - given our approach so far, we cannot impose a constraint saying that everyone has the same employer.

"Our approach so far" is this: we specify any category \\(\mathcal{C}\\) whatsoever as our database schema. Then, a database is a functor \\(F: \mathcal{C} \to \mathbf{Set}\\).

In this approach, if we have two databases

\[ F: \mathcal{C} \to \mathbf{Set} \]

\[ G: \mathcal{C} \to \mathbf{Set} \]

we can always form their sum, or coproduct, or intuitively 'disjoint union'

\[ F + G: \mathcal{C} \to \mathbf{Set} \]

which on objects has

\[ (F + G)(x) := F(x) + G(x) \]

where at right \\(F(x) + G(x)\\) is the disjoint union of the sets \\(F(x)\\) and \\(G(x)\\).

So, if \\(\mathcal{C}\\) has a morphism

\[ \textrm{EmployerOf} : \textrm{Employee} \to \textrm{Person} \]

any database \\(F\\) will say that each employee has one person who is their employee, thanks to the function

\[ F(\textrm{EmployerOf}): F(\textrm{Employee}) \to F(\textrm{Person}). \]

However, we cannot impose the constraint that _everyone has the same employee_, because we can slap two databases together and get

\[ (F+G)(\textrm{EmployerOf}): F(\textrm{Employee}) + G(\textrm{Employee}) \to F(\textrm{Person}) + G(F(\textrm{Person}). \]

There are fancier theories of databases, where we can do more things! But we're starting with the simplest, which has certain limitations.

"Our approach so far" is this: we specify any category \\(\mathcal{C}\\) whatsoever as our database schema. Then, a database is a functor \\(F: \mathcal{C} \to \mathbf{Set}\\).

In this approach, if we have two databases

\[ F: \mathcal{C} \to \mathbf{Set} \]

\[ G: \mathcal{C} \to \mathbf{Set} \]

we can always form their sum, or coproduct, or intuitively 'disjoint union'

\[ F + G: \mathcal{C} \to \mathbf{Set} \]

which on objects has

\[ (F + G)(x) := F(x) + G(x) \]

where at right \\(F(x) + G(x)\\) is the disjoint union of the sets \\(F(x)\\) and \\(G(x)\\).

So, if \\(\mathcal{C}\\) has a morphism

\[ \textrm{EmployerOf} : \textrm{Employee} \to \textrm{Person} \]

any database \\(F\\) will say that each employee has one person who is their employee, thanks to the function

\[ F(\textrm{EmployerOf}): F(\textrm{Employee}) \to F(\textrm{Person}). \]

However, we cannot impose the constraint that _everyone has the same employee_, because we can slap two databases together and get

\[ (F+G)(\textrm{EmployerOf}): F(\textrm{Employee}) + G(\textrm{Employee}) \to F(\textrm{Person}) + G(F(\textrm{Person}). \]

There are fancier theories of databases, where we can do more things! But we're starting with the simplest, which has certain limitations.