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/ ]