From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.science.mathematics.categories/1855 Path: news.gmane.org!not-for-mail From: Nick Rossiter Newsgroups: gmane.science.mathematics.categories Subject: Re: Why binary products are ordered Date: Tue, 13 Feb 2001 18:17:59 +0000 Message-ID: <4.3.1.1.20010213112222.00b612e0@popin.ncl.ac.uk> References: <003201c093cd$c9a89020$cc49393f@cpu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Trace: ger.gmane.org 1241018154 830 80.91.229.2 (29 Apr 2009 15:15:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 29 Apr 2009 15:15:54 +0000 (UTC) To: categories@mta.ca Original-X-From: rrosebru@mta.ca Thu Feb 15 16:08:28 2001 -0400 Return-Path: Original-Received: (from Majordom@localhost) by mailserv.mta.ca (8.11.1/8.11.1) id f1FJWCQ01198 for categories-list; Thu, 15 Feb 2001 15:32:12 -0400 (AST) X-Authentication-Warning: mailserv.mta.ca: Majordom set sender to cat-dist@mta.ca using -f X-Sender: nbnr@popin.ncl.ac.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 In-Reply-To: <003201c093cd$c9a89020$cc49393f@cpu> Original-References: X-Filter-Version: 2.0 (cheviot3) Original-Sender: cat-dist@mta.ca Precedence: bulk X-Keywords: X-UID: 37 Original-Lines: 45 Xref: news.gmane.org gmane.science.mathematics.categories:1855 Archived-At: At 05:54 PM 2/10/01 -0800, Zinovy Diskin wrote: > It became an *annoying* disadvantage when you start to >work in applications (say, relational database theory) with your old habit >to consider relations as sets of ordered tuples. Relational database theory is actually more subtle than this. The extension indeed is a set of ordered n-tuples but this is linked to an intension specifying attribute names and types. The extension is effectively indexed by names in the intension so that ordering of columns is immaterial. Since the ordering of tuples in the extension is also immateial, the model is very flexible. The indexing is in effect from another level. >In ST, you first define tuples (actually, as we've seen, mappings defined >on unordered sets) and *then* a relation is a set of tuples of the >corresponding type. In CT, you *first* define a relation as a set equipped >with a jointly monic family of outgoing mappings (that is, in fact, declare >a special predicate for the corresponding diagram of arrows with common >source) and then, if you need, define a tuple as an element of that set. Cannot such relations be better represented as pullbacks? Limits and colimits then appear to emerge naturally as keys (product thereof) and non-keys (sums) respectively. >The CT-way is a really abstract specification applicable in any context >where objects of interest are organized into a category (say, we may define >what is a relation between the two database schemas). In ST-way, we have >just a particular specification, in fact, an elementwise implementation of >the categorical specification. In sofware engineering terms, one might say >that the CT-way is object-oriented (though actually it's arrow orineted) >since relation appears as a set of objects while the ST-way is >value-oriented since relation is just a table of values. CT certainly appears more powerful at handling object modelling than ST. But I am not sure the relational model is simply value-oriented. The user view is such but the underlying theory (dependencies, normalization, intension-extension mapping, integrity rules) is very much arrow-based and hence also amenable to CT. Regards ... Nick http://www.cs.ncl.ac.uk/people/b.n.rossiter/home.informal/