Re: Re: "Databases are Categories"

[Zinovy Diskin <zdiskin@gsd.uwaterloo.ca>]

2010/8/14 Mattias Wikström <mattias.wikstrom@gmail.com>:
> I think it makes sense to regard database schemas as theories and
> databases as models of such theories. Given a theory T that models

yes, this is the basic underlying assumption in a series of papers of
Michael  Johnson and the moderator of this list.

> some database schema S, a term in the language of T may be thought of
> as a "database query" (to obtain the result of the query, simplify the
> term),

a query is a formula (defining a  derived table) rather than a term

while a statement that two terms in the language of T are equal
> may be thought of as a "database constraint" that one may want to add
> to S.

there are many types of non-equational constraints, for example,
inclusion P=>Q with P,Q formulas

>
> What sort of theory should a database schema be? This surely depends
> on what exactly one is trying to model: A schema in Company A's DBMS
> (database management system) is rarely the same thing as a schema in
> Company B's DBMS, and in any case one probably wants to work with some
> idealised mathematical model.
>

a good question is what the place of SQL on the scale of logical
doctrines is. Since models of SQL-theories include predefined infinite
domains with operations (think of Integer and String), and  finite
domains for tables, model theory for SQL is not classical. I'm not
sure but it seems model-theorists call it "metafinite model theory"
(Gradel and Gurevich).

> David Spivak seems to offer two different answers. On the one hand, a
> database schema may be the same thing as a category. On the other
> hand, a database schema may be a labeled simplicial set. Both answers
> may be found at http://www.uoregon.edu/~dspivak/cs/ .
>

I took a look at the slides of  "databases are categories" talk. It
seems to be an overly simplified model.  Since an employee may work
for several or none departments, data should be modeled by a functor
into Rel rather than Set. 2-category structure may be important, and
we often have a lax functor F(a;b)<F(a);F(b). For example, a Person
_owns_ a Car, which is _parked_ at an Address, where the person
_lives_, but a Person may not have a Car but still _live_ at an
Address (arrow names are underlined, _lives=owns;parked_).
Considering all columns as foreign keys, that is, disregarding the
difference between value-valued and object-valued attributes, would
look very strange for a practitioner.

Z.

> ----------------------------------------
>> Date: Mon, 9 Aug 2010 11:12:34 -0500
>> Subject: categories: "Databases are Categories" (again)
>> From: vigalchin@gmail.com
>> To: categories@mta.ca
>>
>> Hello,
>>
>> I stumbled across this tech talk:
>> http://www.galois.com/blog/2010/05/27/tech-talk-categories-are-databases/ I
>> was wondering
>> what others in this mail list think about Spivak's thesis. I apologize if
>> already posted.
>>
>>
>> Regards,
>>
>> Vasili
>>


[For admin and other information see: http://www.mta.ca/~cat-dist/ ]