Interesting article: In the Beginning: An RDBMS history
x
paul c
> http://www.teradata.com/t/go.aspx/index.html?id=127057
>
>
I notice Colin White mentioned 1,000 pages of SQL standard, which I've
seen something to the effect of before.
Also read somewhere that nowhere does it mention 'relations'. Is
anybody able to confirm this?
(If so, I'm not sure why SQL products claim to be relational, unless
they use tables for the user interface and implement relations under the
covers which would make sense to me although I doubt if any of them go
to that trouble. The reason I say this is that I'm pretty darn sure
I've never seen a relation, except in my mind's eye.)
pc
paul c
> ...
>
> (If so, I'm not sure why SQL products claim to be relational,
maybe they should be called 'skew-al'?
pc
Jonathan Leffler
That's why Date and Darwen have referred to SQL as the Askew Wall; it's
the squiffy wall preventing people from entering Relationland.
--
Jonathan Leffler #include <disclaimer.h>
Email: jlef...@earthlink.net, jlef...@us.ibm.com
Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/
topmind
One can view "relational" on a continous scale. If they satisfy say 10
out of 12 criteria, then one may argue that such is "good enough" to be
called relational.
I am still on the fense about whether such matters much in practice.
Many in-use schemas are so messed due to bad design and historical
cruft up that relational purity is almost an acedemic issue only.
>
> pc
-T-
x
"paul c" <toledob...@oohay.ac> wrote in message
news:GX_Wf.201803$sa3.143853@pd7tw1no...
> Also read somewhere that nowhere does it mention 'relations'. Is
> anybody able to confirm this?
I don't know about the standard but the working drafts are full of
"relationships" :-)
>>5WD-02-Foundation-2003-09:
a)4.14.4 *Relationships* between tables
b)The next Subclauses recursively define the notion of known *functional
dependency*. This is a ternary *relationship* between a table and two sets
of columns of that table. This relationship expresses that a functional
dependency in the table is known to the SQL-implementation.
c)24.3 Implied feature *relationships* of SQL/Foundation
d) 670 The following Language Opportunity has been noted:
Severity: Minor Technical
Reference: P11, SQL/Schemata, Clause 5, "Information Schema"
Note at: None.
Source: DBL:LGW-152/X3H2-97-352 (also DBL:LGW-023/X3H2-97-044, SEQ# 409,
USA-105)
Many "information discovery" products depend upon full text searches of
document databases
to feed the indexing mechanisms used in their search engines. It is very
difficult to extend
this technique to "structured" *relational* databases especially if ...
>>5WD-01-Framework-2003-09:
In other cases, certain SQL objects cannot exist unless some other SQL
object exists, even though there is no
inclusion *relationship*. For example, SQL does not permit an assertion to
exist if some table referenced by the
assertion does not exist.
>>5WD-11-Schemata-2003-09:
The DIRECT_SUPERTABLES base table contains one row for each direct
subtable-supertable *relationship*.
The DIRECT_SUPERTYPES base table contains one row for each direct
subtype-supertype *relationship*.
>>5WD-10-OLB-2003-09:
JDBC provides a complete, low-level SQL interface from Java to *relational*
databases.
>>5WD-14-XML-2003-09:
XML elements are a kind of types. Tables as specified in this paper in the
*relational* world are
mapped to these elements and do not have a named type in the *relational*
domain. We are of
the opinion that this should be preserved in the mapping and lead to
anonymous complex types
in the generated XML Schema.
paul c
Thanks for that, anyway. Maybe I was dreaming about what I thought I
read. I see the word 'relation' doesn't appear in the quotes but maybe
this doesn't matter (assuming that those drafts' other words appear in
the actual standard with the same intended meanings).
Codd, in his 1970 paper, pg 80, said: "Accordingly, we propose that
users deal, not with relations which are domain-ordered, but with
relationships which are their domain-unordered counterparts". In the
next paragraph he says: "To sum up, it is proposed that most users
should interact with a relational model of the data consisting of a
collection of time-varying relationships (rather than relations".
It seems that by using the word "relationship" he was merely trying to
draw a line between mathematical relations that have ordered domains and
ones that replace the ordering with names as well as between logical and
physical representations. (By "most users" in the second sentence I'm
guessing that he was talking about everybody except DBA's.) Also seems
that what he meant by 'relationship' was roughly what we call 'relation'
today.
So I guess it would be reasonable for the standard to use "relationship"
as long as it clarifies where it uses that word in some special sense,
such as when talking about functional dependencies which seems to me to
throw 'relationship', 'table' and 'columns' up in the air and let them
land on the floor however they may. That heading 4.14.4 about
"Relationships between tables" seems murky since Codd's 1970 paper
AFAICT mentions tables only in the sense of 'data description tables'
(presumably in the dictionaries of the hierarchical products of those
times, the 1969 paper doesn't seem to mention them at all). Either that
or define such terms at the beginning - maybe it does, I'm too cheap to
buy it.
p
jonathan...@gmail.com
paul c wrote:
> I notice Colin White mentioned 1,000 pages of SQL standard, which I've
> seen something to the effect of before.
SQL 2003 comes in multiple parts:
* 9075-1: SQL/Framework
* 9075-2: SQL/Foundation
* 9075-3: SQL/CLI
* 9075-4: SQL/PSM
* 9075-9: SQL/MED
* 9075-10: SQL/OLB
* 9075-11: SQL/Schemata
* 9075-13: SQL/JRT
* 9075-14: SQL/XML
The PDF file of part 2 (SQL/Foundation) has 1267 pages.
Part 1: 82 pages
Part 2: 1267
Part 3: 405
Part 4: 184
Part 9: 501
Part 10: 402
Part 11: 296
Part 13: 204
Part 14: 267
> Also read somewhere that nowhere does it mention 'relations'. Is
> anybody able to confirm this?
Yes. Part 2 does not mention 'relational' or 'relation'; it does
mention relationship but means how two tables are related or how SQL
features are related. The most common match for 'relation' is
'correlation'. Part 1 is similar - I didn't check the rest but would
not expect them to be any different.
x
> x wrote:
> > "paul c" <toledob...@oohay.ac> wrote in message
> > news:GX_Wf.201803$sa3.143853@pd7tw1no...
> >
> Thanks for that, anyway. Maybe I was dreaming about what I thought I
> read. I see the word 'relation' doesn't appear in the quotes but maybe
> this doesn't matter (assuming that those drafts' other words appear in
> the actual standard with the same intended meanings).
I think Jonathan Leffler was right when he mentioned the word
"relationships" may refer to something else.
For example I've seen it used for <, >, >=, = among other things :-)
> Codd, in his 1970 paper, pg 80, said: "Accordingly, we propose that
> users deal, not with relations which are domain-ordered, but with
> relationships which are their domain-unordered counterparts". In the
> next paragraph he says: "To sum up, it is proposed that most users
> should interact with a relational model of the data consisting of a
> collection of time-varying relationships (rather than relations".
> It seems that by using the word "relationship" he was merely trying to
> draw a line between mathematical relations that have ordered domains and
> ones that replace the ordering with names as well as between logical and
> physical representations. (By "most users" in the second sentence I'm
> guessing that he was talking about everybody except DBA's.) Also seems
> that what he meant by 'relationship' was roughly what we call 'relation'
> today.
About "domain ordered".
What do you think is the difference between the Codd pi
(projection/permutation) operator and Chris Date rename coupled with
projection operators ?
To me they appear to be the same.
For example pi21(supply{project, supplier}) appear to be
select project as supplier, supplier as project from supply
> So I guess it would be reasonable for the standard to use "relationship"
> as long as it clarifies where it uses that word in some special sense,
> such as when talking about functional dependencies which seems to me to
> throw 'relationship', 'table' and 'columns' up in the air and let them
> land on the floor however they may. That heading 4.14.4 about
> "Relationships between tables" seems murky since Codd's 1970 paper
> AFAICT mentions tables only in the sense of 'data description tables'
> (presumably in the dictionaries of the hierarchical products of those
> times, the 1969 paper doesn't seem to mention them at all).
They use "relationships" for a lot of things.
It appear they use the relational model to implement the SQL but they don't
allow the users to take advantage of it.
paul c
> "paul c" <toledob...@oohay.ac> wrote in message
> news:xPbYf.218029$B94.60669@pd7tw3no...
>
>>x wrote:
>>
>>>"paul c" <toledob...@oohay.ac> wrote in message
>>>news:GX_Wf.201803$sa3.143853@pd7tw1no...
>>>
>
>
>>Thanks for that, anyway. Maybe I was dreaming about what I thought I
>>read. I see the word 'relation' doesn't appear in the quotes but maybe
>>this doesn't matter (assuming that those drafts' other words appear in
>>the actual standard with the same intended meanings).
>
>
> I think Jonathan Leffler was right when he mentioned the word
> "relationships" may refer to something else.
> For example I've seen it used for <, >, >=, = among other things :-)
>
Being as thorough as he usually is, I'm sure Jonathan's right too. I'm
darned if I know what a "relationship between tables" is unless it's
another table. For that matter, I don't know what the sql standard
would mean by "table" (assuming it uses that word). I've assumed that
it doesn't stand for a relation partly because it allows duplicates and
nulls. Without those differences, I imagine an sql table still couldn't
stand for any relation we choose because at least when I was using it
ten or more years ago a row-column intersection contained only a single
value, ie. some relations can't be expressed as one table.
>
>>Codd, in his 1970 paper, pg 80, said: "Accordingly, we propose that
>>users deal, not with relations which are domain-ordered, but with
>>relationships which are their domain-unordered counterparts". In the
>>next paragraph he says: "To sum up, it is proposed that most users
>>should interact with a relational model of the data consisting of a
>>collection of time-varying relationships (rather than relations".
>>It seems that by using the word "relationship" he was merely trying to
>>draw a line between mathematical relations that have ordered domains and
>>ones that replace the ordering with names as well as between logical and
>>physical representations. (By "most users" in the second sentence I'm
>>guessing that he was talking about everybody except DBA's.) Also seems
>>that what he meant by 'relationship' was roughly what we call 'relation'
>>today.
>
>
> About "domain ordered".
>
> What do you think is the difference between the Codd pi
> (projection/permutation) operator and Chris Date rename coupled with
> projection operators ?
>
> To me they appear to be the same.
>
> For example pi21(supply{project, supplier}) appear to be
> select project as supplier, supplier as project from supply
>
I'm not sure. I thought Codd said that he was using arrays just as a
way of explaining the operators.
>
>
>
>>So I guess it would be reasonable for the standard to use "relationship"
>>as long as it clarifies where it uses that word in some special sense,
>>such as when talking about functional dependencies which seems to me to
>> throw 'relationship', 'table' and 'columns' up in the air and let them
>>land on the floor however they may. That heading 4.14.4 about
>>"Relationships between tables" seems murky since Codd's 1970 paper
>>AFAICT mentions tables only in the sense of 'data description tables'
>>(presumably in the dictionaries of the hierarchical products of those
>>times, the 1969 paper doesn't seem to mention them at all).
>
>
> They use "relationships" for a lot of things.
> It appear they use the relational model to implement the SQL but they don't
> allow the users to take advantage of it.
>
>
"They" included some smart people so that could well have been in the
back of their minds but if the standard doesn't mention 'relation' it
would seem that it would be incapable of saying that which I think it
ought to if that's what's intended. After all, smart people aren't
always right!
Anyway, Jonathan's count of 1279 pages for the 'fundamentals' seems
pretty damning to me. Would mean an individual's life work to
understand it unless it is organized extremely well, eg. 50 actual
fundamental pages and 1229 of explanation/exposition.
p
David Cressey
> x wrote:
> I'm not sure. I thought Codd said that he was using arrays just as a
> way of explaining the operators.
I don't think so. I think he was making the distinction between attributes
specified by name and attributes specified by position.
x
"David Cressey" <dcre...@verizon.net> wrote in message
news:kCTYf.7149$g81.1159@trndny09...
What is the difference between a "name" and a "position" from a
mathematically point of view ?
Jon Heggland
> I'm darned if I know what a "relationship between tables" is unless
> it's another table.
In my experience, it's rather common to use that phrase for foreign keys.
> For that matter, I don't know what the sql standard
> would mean by "table" (assuming it uses that word). I've assumed that
> it doesn't stand for a relation partly because it allows duplicates and
> nulls. Without those differences, I imagine an sql table still couldn't
> stand for any relation we choose because at least when I was using it
> ten or more years ago a row-column intersection contained only a single
> value, ie. some relations can't be expressed as one table.
Hm?
--
Jon
paul c
> paul c wrote:
>
>>I'm darned if I know what a "relationship between tables" is unless
>>it's another table.
>
>
> In my experience, it's rather common to use that phrase for foreign keys.
>
In a 'standard' that people rely on to make exact decisions, what good
is it to use it that way? Wouldn't it be better to say exactly what it
is, for example, one projection is a subset of the other?
>
>>For that matter, I don't know what the sql standard
>>would mean by "table" (assuming it uses that word). I've assumed that
>>it doesn't stand for a relation partly because it allows duplicates and
>>nulls. Without those differences, I imagine an sql table still couldn't
>>stand for any relation we choose because at least when I was using it
>>ten or more years ago a row-column intersection contained only a single
>>value, ie. some relations can't be expressed as one table.
>
>
> Hm?
For sure, any single-rva-attribute relation, maybe others too.
p
David Cressey
"x" <x...@not-exists.org> wrote in message news:e12djb$ha2$1...@emma.aioe.org...
> > I don't think so. I think he was making the distinction between
> attributes
> > specified by name and attributes specified by position.
>
> What is the difference between a "name" and a "position" from a
> mathematically point of view ?
I can't speak for Codd on this, and I don't choose to speak for myself.
dawn
The only difference is the domain for the function, whether it is a set
of counting numbers or a set of attribute names. If counting numbers,
then there is an obvious order (function), represented as the order of
a tuple.
It amuses me when people make a big deal about there being no order of
the attributes in a relation (which is then not strictly a relation as
Codd pointed out). Given that attributes are specified to the system
in some order (create table...) and output in some order, what do I
care if under the covers it knows a mapping from the counting numbers
to the attribute values or from attribute names to attribute values or
both?
Cheers! --dawn
David Cressey
"dawn" <dawnwo...@gmail.com> wrote in message
news:1144354101.8...@z34g2000cwc.googlegroups.com...
>
> David Cressey wrote:
> > "x" <x...@not-exists.org> wrote in message
news:e12djb$ha2$1...@emma.aioe.org...
> > > > I don't think so. I think he was making the distinction between
> > > attributes
> > > > specified by name and attributes specified by position.
> > >
> > > What is the difference between a "name" and a "position" from a
> > > mathematically point of view ?
> >
> > I can't speak for Codd on this, and I don't choose to speak for myself.
>
> The only difference is the domain for the function, whether it is a set
> of counting numbers or a set of attribute names. If counting numbers,
> then there is an obvious order (function), represented as the order of
> a tuple.
This is not true.
If the numbers were explictily used as if they were names, in every place
where a specific attribute is specified, your statement would be true.
However, if attributes are expressed in the form of a list, as they are in
mathematics when discussing relations, then the mapping between attributes
and values is based on position in the list.
However, that was not Codd's point.
Codd's point was that users should not have to remember "names" like 23, 24,
25, ...etc. in order to specify attributes in a query.
>
> It amuses me when people make a big deal about there being no order of
> the attributes in a relation (which is then not strictly a relation as
> Codd pointed out). Given that attributes are specified to the system
> in some order (create table...) and output in some order, what do I
> care if under the covers it knows a mapping from the counting numbers
> to the attribute values or from attribute names to attribute values or
> both?
A lot of things amuse you.
In this case, your amusement stems from the fact that you view the text that
represents a create table as being the create table itself. The source code
for a Lisp program is a string of characters. But the actual Lisp program
is a data structure in memory. The Lisp program can have a structure (like
tree structure) that the text source can only express indirectly, through
the use of parentheses.
paul c
>>
>>The only difference is the domain for the function, whether it is a set
>>of counting numbers or a set of attribute names. If counting numbers,
>>then there is an obvious order (function), represented as the order of
>>a tuple.
>
>
> This is not true.
>
> If the numbers were explictily used as if they were names, in every place
> where a specific attribute is specified, your statement would be true.
> However, if attributes are expressed in the form of a list, as they are in
> mathematics when discussing relations, then the mapping between attributes
> and values is based on position in the list.
>
> However, that was not Codd's point.
>
> Codd's point was that users should not have to remember "names" like 23, 24,
> 25, ...etc. in order to specify attributes in a query.
Plus, I think, that the numbers would "change" after relops were applied
(they do in Codd's examples). Maybe this is what "x" had in mind - kind
of like the system doing the rename for you, the price being that you
can't guess what the new "names" are going to be!
p
dawn
David Cressey wrote:
> "dawn" <dawnwo...@gmail.com> wrote in message
> news:1144354101.8...@z34g2000cwc.googlegroups.com...
> >
> > David Cressey wrote:
> > > "x" <x...@not-exists.org> wrote in message
> news:e12djb$ha2$1...@emma.aioe.org...
> > > > > I don't think so. I think he was making the distinction between
> > > > attributes
> > > > > specified by name and attributes specified by position.
> > > >
> > > > What is the difference between a "name" and a "position" from a
> > > > mathematically point of view ?
> > >
> > > I can't speak for Codd on this, and I don't choose to speak for myself.
> >
> > The only difference is the domain for the function, whether it is a set
> > of counting numbers or a set of attribute names. If counting numbers,
> > then there is an obvious order (function), represented as the order of
> > a tuple.
>
> This is not true.
>
> If the numbers were explictily used as if they were names, in every place
> where a specific attribute is specified, your statement would be true.
I don't see how a function being explicitly written or not makes any
difference. In some systems you can refer to an attribute either by
name or number. They serve as two different names for the attributes.
> However, if attributes are expressed in the form of a list, as they are in
> mathematics when discussing relations, then the mapping between attributes
> and values is based on position in the list.
>
> However, that was not Codd's point.
>
> Codd's point was that users should not have to remember "names" like 23, 24,
> 25, ...etc. in order to specify attributes in a query.
I would have to re-read things to be sure, but I thought perhaps his
concern was over decoupling the logical and physical model of the
attributes. In systems where attributes are referred by numbers, there
is often a correlation between the logical and physical order, although
there need not be.
> > It amuses me when people make a big deal about there being no order of
> > the attributes in a relation (which is then not strictly a relation as
> > Codd pointed out). Given that attributes are specified to the system
> > in some order (create table...) and output in some order, what do I
> > care if under the covers it knows a mapping from the counting numbers
> > to the attribute values or from attribute names to attribute values or
> > both?
>
> A lot of things amuse you.
Indeed.
> In this case, your amusement stems from the fact that you view the text that
> represents a create table as being the create table itself.
I most certainly do not. Are you suggesting there really is some valid
reason for insisting that there be no function mapping a subset of the
natural numbers to attribute values? I can imagine someone concerned
about maintaining that ordering or some such, but if that is done by
the dbms software, who cares? How bad would it be if you got
attributes in the exact same order each time you did a select *? ;-)
--dawn
JOG
> David Cressey wrote:
> > "dawn" <dawnwo...@gmail.com> wrote in message
> > news:1144354101.8...@z34g2000cwc.googlegroups.com...
> > >
> > > David Cressey wrote:
> > > > "x" <x...@not-exists.org> wrote in message
> > news:e12djb$ha2$1...@emma.aioe.org...
> > > > > > I don't think so. I think he was making the distinction between
> > > > > attributes
> > > > > > specified by name and attributes specified by position.
> > > > >
> > > > > What is the difference between a "name" and a "position" from a
> > > > > mathematically point of view ?
> > > >
> > > > I can't speak for Codd on this, and I don't choose to speak for myself.
> > >
> > > The only difference is the domain for the function, whether it is a set
> > > of counting numbers or a set of attribute names. If counting numbers,
> > > then there is an obvious order (function), represented as the order of
> > > a tuple.
> >
> > This is not true.
> >
> > If the numbers were explictily used as if they were names, in every place
> > where a specific attribute is specified, your statement would be true.
>
> I don't see how a function being explicitly written or not makes any
> difference. In some systems you can refer to an attribute either by
> name or number. They serve as two different names for the attributes.
>
I think I agree with David here Dawn, that there is a subtle difference
- given a mathematical relation is a list of elements (whose order is
specified by the order of its domains), when one refers to the 'first'
or 'second' element one is using knowledge external to the model in
order to ascertain which domain each element corresponds to. My
impression was that Codd believed the cognitive load of maintaining
this meta-knowledge to be deleterious, and so added attribute naming.
Being aware of this subtle distinction he proposed a name change to
'relationship' (which I learnt from yourself in fact). I'm not sure I
have the vocabulary to express this succinctly yet.
all best, J.
Marshall Spight
>
> Are you suggesting there really is some valid
> reason for insisting that there be no function mapping a subset of the
> natural numbers to attribute values? I can imagine someone concerned
> about maintaining that ordering or some such, but if that is done by
> the dbms software, who cares? How bad would it be if you got
> attributes in the exact same order each time you did a select *? ;-)
The choice between a numerical vs. symbolic identification of
attributes
is purely syntactic. One or the other, they have the exactly same
computational power, although they require substantially different
syntax to express the same things.
But wanting to have both at the same time, while it seems innocuous
enough, actually leads to the loss of important algebraic properties.
It seems like it can be reconciled, but I am convinced it can't, at
least not without some loss.
(This is not to say that you can't have some *separate* numeric-to-
name mapping, or multiple such, and use one in one context and
another in another; there's nothing wrong with that. The problem
comes in trying to have the mapping be part of the value, or part
of the type.)
For example, if one has some relations R[a,b] and S[b,c],
(here, use of [] indicates the attributes are ordered) and
one does a natural join, what shall be the order of the resulting
columns? If the proposal is R join S has columns, in order, [a,b,c],
then that means that S join R would have column [c,b,a], which
would mean that natural join would no longer be commutative.
You can try to escape by proposing that the order of the columns
not be relevant in determining equality, but then that breaks
substitutibility.
I'm too tired to write up the substitutibility problem right now.
I'll just mention that I spent long time trying to devise a
syntax and semantics that would hold all the design value
of named attributes with all the notational convenience of
positional attributes, and I couldn't make it work. The
problems are subtle, but pernicious.
Marshall
dawn
I don't dispute that there is a difference. I just don't see what is
so problematic about it.
> - given a mathematical relation is a list of elements (whose order is
> specified by the order of its domains), when one refers to the 'first'
> or 'second' element one is using knowledge external to the model
unless you include it in the model, in which case it is part of the
model. A reason why it might be an advantage in a model is if you did
not want to fix the attribute name or want to have synonyms without
designating one as most important. These are both viable for a data
model, even if not part of the RM.
> in
> order to ascertain which domain each element corresponds to. My
> impression was that Codd believed the cognitive load of maintaining
> this meta-knowledge to be deleterious,
That could be. I would also agree it is easier to remember an
attribute name than number.
> and so added attribute naming.
> Being aware of this subtle distinction he proposed a name change to
> 'relationship' (which I learnt from yourself in fact).
Yes, he writes that in the 1970 paper. In what Pascal calls "Dawn's
Proof" or something like that, I made a joke about the fact that the MV
model, which does have an ordering (which relates to a physical
ordering, admittedly) actually models the data in relations (rather
than relationships) so (I claimed, tongue in cheek) it is more
relational than the RM. While Fabian claims that to be my proof that
the MV is relational, I have always held that the Pick model clearly
pre-dates and is different from the RM.
Outside of the issue of how coupled a logical model is to the physical
model, I see no harm in numbering the attributes provided you also name
them. I have seen statements about how the attributes must be
unordered written by several RM authors. It just seems to be an
unimportant and unnecessary point. Cheers! --dawn
dawn
We could surely define an order then, but I see your point in this
regard. Similarly if you do a union or look at equality. Each of
these could ignore the ordering, but if the ordering were required, it
would have to come up with something for the result.
> If the proposal is R join S has columns, in order, [a,b,c],
> then that means that S join R would have column [c,b,a], which
> would mean that natural join would no longer be commutative.
Since I'm not starting with theory but with an actual example, that
example performs joins, for example while ignoring ordering. When
performing any set operations (with SQL) the order is unused data.
When performing typical reads and writes, however (not with SQL), the
order is what is used and the attribute names are just synonyms for the
number of the attribute.
> You can try to escape by proposing that the order of the columns
> not be relevant in determining equality, but then that breaks
> substitutibility.
>
> I'm too tired to write up the substitutibility problem right now.
> I'll just mention that I spent long time trying to devise a
> syntax and semantics that would hold all the design value
> of named attributes with all the notational convenience of
> positional attributes, and I couldn't make it work. The
> problems are subtle, but pernicious.
OK, I'll think about that. Of course it _works_ for a dbms to retain
such ordering (examples are numerous), but it is not then an RDBMS. If
you don't work with set operations, but with graph navigation, do you
still have these issues? I recall an odd situation where I had to
reorder attributes to do a union. That is the only time I can recall
wishing the attributes were not ordered. It didn't bother me when
working with SQL since the ordering was then ignored.
This is a seemingly tiny detail, of course, but it comes up more often
than one might guess in the RM literature as if it were problematic and
it just doesn't seem to be in practice. I'll grant I'm not working
with a strictly RDBMS product (but who is?)
--dawn
Jonathan Leffler
> paul c wrote:
>> I'm darned if I know what a "relationship between tables" is unless
>> it's another table.
>
> In my experience, it's rather common to use that phrase for foreign keys.
No - not foreign keys etc. There are a few odd-ball characters encoded
in UTF-8 (they are 'curved less than' and 'curved greater than' symbols,
I think - mathematical symbols and my Unicode standard is at the office
so I can't find the official name easily).
SQL/Foundation Section 4.14.4 "Relationships between tables".
Section 24.4 "Implied feature relationships of SQL/Foundation"
4.2.2 Comparison of character strings
[...]
A collation is defined by ISO/IEC 14651 as “a process by which two
strings are determined to be in exactly one of the relationships of less
than, greater than, or equal to one another”.
<enjoy>
4.14.4 Relationships between tables
The terms simply underlying table, underlying table, leaf underlying
table, generally underlying table, and leaf generally underlying table
define a relationship between a derived table or cursor and other tables.
The simply underlying tables of derived tables and cursors are defined
in Subclause 7.12, “<query specification>”, Subclause 7.13, “<query
expression>”, and Subclause 14.1, “<declare cursor>”. A <table or query
name> has no simply underlying tables.
The underlying tables of a derived table or cursor are the simply
underlying tables of the derived table or cursor and the underlying
tables of the simply underlying tables of the derived table or cursor.
The leaf underlying tables of a derived table or cursor are the
underlying tables of the derived table or cursor that do not themselves
have any underlying tables.
The generally underlying tables of a derived table or cursor are the
underlying tables of the derived table or cursor and, for each
underlying table of the derived table or cursor that is a <table or
query name> TORQN, the generally underlying tables of TORQN, which are
defined as follows:
</enjoy>
<more fun>
4.18.2 General rules and definitions
[...]
The next Subclauses recursively define the notion of known functional
dependency. This is a ternary relationship between a table and two sets
of columns of that table. This relationship expresses that a functional
dependency in the table is known to the SQL-implementation. All
axiomatic functional dependencies are known functional dependencies. In
addition, any functional dependency that can be deduced from known
functional dependencies using the rules of deduction for functional
dependency is a known functional dependency.
</more fun>
9.5 Type precedence list determination
[...]
b) Let PTC be the set of all precedence relationships determined as
follows: For any two types T1 and T2, not necessarily distinct, in NDT,
Case:
i) If T1 is exact numeric and T2 is approximate numeric, then T1 ≺ T2.
ii) If T1 is approximate numeric and T2 is exact numeric, then T1 ≻ T2.
iii) If the effective binary precision of T1 is greater than the
effective binary precision of T2, then T2 ≺ T1.
iv) If the effective binary precision of T1 equals the effective binary
precision of T2, then T2 ≃ T1.
v) Otherwise, T1 ≺ T2.
c) TPL is determined as follows:
i) TPL is initially empty.
ii) Let ST be the set of types containing DT and every type T in NDT for
which the precedence relationship DT ≺ T or DT ≃ T is in PTC.
iii) Let n be the number of types in ST.
iv) For i ranging from 1 (one) to n:
1) Let NT be the set of types Tk in ST such that there is no other type
Tj in ST for which Tj ≺ Tk according to PTC.
2) Case:
A) If there is exactly one type Tk in NT, then Tk is placed next in TPL
and all relationships of the form Tk ≺ Tr are removed from PTC, where Tr
is any type in ST.
[...more turgid prose removed... That was Syntax Rule 8.c.iv.2.A in
section 9.5, I note!...and there was a relationship ion 8.c.iv.2.B...]
Section 10.2 <language clause>
1) The standard programming language specified by the <language clause>
is defined in the International Standard identified by the <language
name> keyword. Table 15, “Standard programming languages”, specifies the
relationship.
Section 19.1 Description of SQL descriptor areas
NOTE 426 — “Matches” and “represented by”, as applied to the
relationship between a data type and an SQL item descriptor area
are defined in the Syntax Rules of this Subclause.
Four notes in 19.10 <input using clause> and 19.11 <output using clause>
along the lines of:
NOTE 434 — “Represented by”, as applied to the relationship between a
data type and an item descriptor area, is defined in the Syntax Rules of
Subclause 19.1, “Description of SQL descriptor areas”.
Section 24.3 Implied Feature Relationships of SQL/Foundation
A 4-column table:
Feature | Feature Name | Implied | Implied
ID | | Feature ID | Feature Name
B032 | Extended dynamic SQL | B031 | Basic dynamic SQL
B034 | Dynamic specification | B031 | Basic dynamic SQL
| of cursor attributes | |
B111 | Module language Ada | E182 | Module language
It is on three pages in total...
Jon Heggland
> Jon Heggland wrote:
>> paul c wrote:
>>> I'm darned if I know what a "relationship between tables" is unless
>>> it's another table.
>>
>> In my experience, it's rather common to use that phrase for foreign keys.
>
> In a 'standard' that people rely on to make exact decisions, what good
> is it to use it that way?
Who knows? My impression of the SQL standard's quality, clarity and
consistency isn't very favourable. I'm not saying that that is the
correct interpretation of the phrase in this case, just that it is a
possibility.
> Wouldn't it be better to say exactly what it
> is, for example, one projection is a subset of the other?
Perhaps, if that is what they mean. That is not completely equivalent to
a foreign key in the normal sense of the term, though.
>>> For that matter, I don't know what the sql standard
>>> would mean by "table" (assuming it uses that word). I've assumed that
>>> it doesn't stand for a relation partly because it allows duplicates and
>>> nulls. Without those differences, I imagine an sql table still couldn't
>>> stand for any relation we choose because at least when I was using it
>>> ten or more years ago a row-column intersection contained only a single
>>> value, ie. some relations can't be expressed as one table.
>>
>> Hm?
>
> For sure, any single-rva-attribute relation, maybe others too.
Ok. I would say that a relation value *is* a single value, but I don't
want another fruitless 1NF debate. :) I'd rephrase your argument to say
that an sql table can't stand for any relvar we choose because SQL
doesn't support arbitrary user-defined types. Anyway, I would think that
"table" is one of the terms the SQL standard defines (implicitly or
explicitly), but I can't say for sure.
--
Jon
Jan Hidders
>
> Outside of the issue of how coupled a logical model is to the physical
> model, I see no harm in numbering the attributes provided you also name
> them.
It also makes the theory more complicated than necessary. What if we
take the join of two relations, what is then the order of the
attributes in the resulting table? How do you define this such that a
join is still commutative? This is rather crucial for quey
optimization. And what about unions? Are they allowed already if the
set of attributes is the same, or does their order also have to be the
same? If the orders are allowed to differ, how is then the order in the
result of the union defined in such a way that we keep the usual
algebraic identies?
-- Jan Hidders
JOG
If one just looks at the maths of a simple example. Consider a
relation(ship) of fruit:
fruit = {
{ (name, apple), (colour, green), (size, medium) }
{ (name, banana), (colour, yellow), (size, large) }
{ (name, date), (colour, brown), (size, small) }
}
There's no getting away from the fact that because each 'tuple' is just
a set of attribute/value pairs the order we write them down in is
necessarily unimportant. To refer to them positionally, now that this
is an RM-relation and not a purely mathematical-relation, every single
tuple must have a common ordering applied to it. So for the first
'tuple', if we say:
fruit_order = {
( (name, apple), (colour, green) ) ,
( (colour, green), (name, apple) )
}
and apply an equivalent ordering to this for all rows, only then can we
(mathematically) refer to each attribute/value by its position.
There clearly exists no mechanism for implementing or extracting such
orderings to an RM-relation (and if there was, how would it be affected
by Joins? I imagine generating a partial ordering would be the simplest
solution). Perhaps there should?
>
> > - given a mathematical relation is a list of elements (whose order is
> > specified by the order of its domains), when one refers to the 'first'
> > or 'second' element one is using knowledge external to the model
>
> unless you include it in the model, in which case it is part of the
> model. A reason why it might be an advantage in a model is if you did
> not want to fix the attribute name or want to have synonyms without
> designating one as most important. These are both viable for a data
> model, even if not part of the RM.
The only way I can see to include ordinal position within the model is
as my last paragraph. Cardinal labels are of course no different from
any other other field name, but as a pickie you'd prefer ordinality no?
>
> > in
> > order to ascertain which domain each element corresponds to. My
> > impression was that Codd believed the cognitive load of maintaining
> > this meta-knowledge to be deleterious,
>
> That could be. I would also agree it is easier to remember an
> attribute name than number.
>
> > and so added attribute naming.
> > Being aware of this subtle distinction he proposed a name change to
> > 'relationship' (which I learnt from yourself in fact).
>
> Yes, he writes that in the 1970 paper. In what Pascal calls "Dawn's
> Proof" or something like that, I made a joke about the fact that the MV
> model, which does have an ordering (which relates to a physical
> ordering, admittedly) actually models the data in relations (rather
> than relationships) so (I claimed, tongue in cheek) it is more
> relational than the RM. While Fabian claims that to be my proof that
> the MV is relational, I have always held that the Pick model clearly
> pre-dates and is different from the RM.
Aye, saying things tongue cheek seems to be a minefield if people have
the urge to use it to club you with later on, because it can never
maintain its original context.
>
> Outside of the issue of how coupled a logical model is to the physical
> model, I see no harm in numbering the attributes provided you also name
> them. I have seen statements about how the attributes must be
> unordered written by several RM authors. It just seems to be an
> unimportant and unnecessary point. Cheers! --dawn
I think i'm just emphasising the difference between ordinality and
cardinality.
All best, J.
JOG
fruit_order = {
( (name, apple), (colour, green) ) ,
( (colour, green), (size, medium) )
}
x
"JOG" <j...@cs.nott.ac.uk> wrote in message
news:1144408386.0...@z34g2000cwc.googlegroups.com...
> If one just looks at the maths of a simple example. Consider a
> relation(ship) of fruit:
> fruit = {
> { (name, apple), (colour, green), (size, medium) }
> { (name, banana), (colour, yellow), (size, large) }
> { (name, date), (colour, brown), (size, small) }
> }
> There's no getting away from the fact that because each 'tuple' is just
> a set of attribute/value pairs the order we write them down in is
> necessarily unimportant.
Curiously, you wrote the tuples in the *order* name, colour, size.
When people write some names in no particular order they usually write them
in alphabetical *order* and add some phrase to explain that the order is
pure alphabetical :-)
>To refer to them positionally, now that this
> is an RM-relation and not a purely mathematical-relation, every single
> tuple must have a common ordering applied to it. So for the first
> 'tuple', if we say:
>
> fruit_order = {
> ( (name, apple), (colour, green) ) ,
> ( (colour, green), (size, medium) )
> }
>
> and apply an equivalent ordering to this for all rows, only then can we
> (mathematically) refer to each attribute/value by its position.
What is the relation for the above ?.
> There clearly exists no mechanism for implementing or extracting such
> orderings to an RM-relation (and if there was, how would it be affected
> by Joins? I imagine generating a partial ordering would be the simplest
> solution). Perhaps there should?
> >
> > > - given a mathematical relation is a list of elements (whose order is
> > > specified by the order of its domains), when one refers to the 'first'
> > > or 'second' element one is using knowledge external to the model
> >
> > unless you include it in the model, in which case it is part of the
> > model. A reason why it might be an advantage in a model is if you did
> > not want to fix the attribute name or want to have synonyms without
> > designating one as most important. These are both viable for a data
> > model, even if not part of the RM.
> The only way I can see to include ordinal position within the model is
> as my last paragraph. Cardinal labels are of course no different from
> any other other field name, but as a pickie you'd prefer ordinality no?
I remember that the order of the rows is also irrelevant.
Why we name attributes with strings and we don't name the rows ? :-)
Why not the other way around ? :-)
dawn
> dawn wrote:
> >
> > Outside of the issue of how coupled a logical model is to the physical
> > model, I see no harm in numbering the attributes provided you also name
> > them.
>
> It also makes the theory more complicated than necessary. What if we
> take the join of two relations, what is then the order of the
> attributes in the resulting table?
Yes, I responded to Marshall on this. I can see that this ordering is
outside of relational operators. One way it is handled is to have only
stored data include an ordering which is not present in any derived
views.
> How do you define this such that a
> join is still commutative? This is rather crucial for quey
> optimization.
I can see that would be the case if using a set-based query language.
> And what about unions? Are they allowed already if the
> set of attributes is the same, or does their order also have to be the
> same? If the orders are allowed to differ, how is then the order in the
> result of the union defined in such a way that we keep the usual
> algebraic identies?
Yes, when doing set operations on an ordered set of attributes,
everything is handled as if the ordering were not there. So, the
ordering is irrelevant to SQL, but employed by other languages working
with the data. I don't know that it is ideal to have this, but it
doesn't seem to be a problem to model the stored data as actual
relations (with attributes ordered) either. --dawn
David Cressey
> Yes, when doing set operations on an ordered set of attributes,
> everything is handled as if the ordering were not there. So, the
> ordering is irrelevant to SQL, but employed by other languages working
> with the data. I don't know that it is ideal to have this, but it
> doesn't seem to be a problem to model the stored data as actual
> relations (with attributes ordered) either. --dawn
SQL is by no means ideal when it comes to whether ordering is implicit in
the language.
Consider the following:
INSERT INTO fubar (blech, zork, zonk)
SELECT bimbo as zonk, jimbo as blech, zimbo as zork from xyzzy;
Anyone would think that zonk would go into zonk, blech would go into blech,
and zork would go into zork.
Ahh but no! (At least not in the SQL diealects I am used to). The matchup
is by position.
The same for
INSERT INTO fubar (blech, zork, zonk)
VALUES ( 'A', 'B', 'C');
Jon Heggland
> Yes, when doing set operations on an ordered set of attributes,
> everything is handled as if the ordering were not there. So, the
> ordering is irrelevant to SQL,
FYI: SQL's set operations are based on attribute ordering. There are
variant set operations in the standard that are based on attribute names
instead (a CORRESPONDING keyword, IIRC), but I don't know if anyone have
implemented them.
--
Jon
mAsterdam
> David Cressey wrote:
>>>David Cressey wrote:
>>>>x wrote:
>>>>>I don't think so. I think he was making the distinction between
>>>>>attributes specified by name and attributes
>>>>>specified by position.
>>>>>
>>>>>What is the difference between a "name" and a "position" from a
>>>>>mathematically point of view ?
>>>>
>>>>I can't speak for Codd on this, and I don't choose to speak for myself.
>>>
>>>The only difference is the domain for the function, whether it is a set
>>>of counting numbers or a set of attribute names. If counting numbers,
>>>then there is an obvious order (function), represented as the order of
>>>a tuple.
>>
>>This is not true.
>>
>>If the numbers were explictily used as if they were names, in every place
>>where a specific attribute is specified, your statement would be true.
>
>
> I don't see how a function being explicitly written or not makes any
> difference. In some systems you can refer to an attribute either by
> name or number. They serve as two different names for the attributes.
.... as long as the model (of the universe of discourse)
does *not* change. It will.
As soon as it does change (e.g. add/scratch an
attribute/column/field/whatever horizontal thingy)
the /number/ references have to be re-examined whereas the /name/
simply continues to refer to the correct (as
correct as it was to begin with) data.
Design principle: Look for the invariant to elicit
a dependable structure.
[snip]
>>Codd's point was that users should not have to remember "names" like 23, 24,
>>25, ...etc. in order to specify attributes in a query.
>
>
> I would have to re-read things to be sure, but I thought perhaps his
> concern was over decoupling the logical and physical model of the
> attributes. In systems where attributes are referred by numbers, there
> is often a correlation between the logical and physical order, although
> there need not be.
Exegesis is not my hobby. I thought it wasn't yours either.
[snip]
>>A lot of things amuse you.
> Indeed.
:-)
mAsterdam
> dawn wrote:
>
>>Are you suggesting there really is some valid
>>reason for insisting that there be no function mapping a subset of the
>>natural numbers to attribute values? I can imagine someone concerned
>>about maintaining that ordering or some such, but if that is done by
>>the dbms software, who cares? How bad would it be if you got
>>attributes in the exact same order each time you did a select *? ;-)
>
>
> The choice between a numerical vs. symbolic identification of
> attributes is purely syntactic.
I can not agree with that.
First a frame of reference.
Supporting levels, low to high:
(fatic -) syntactic - semantic - pragmatic.
Numerical vs. symbolic identification of attributes has
consequences (i.e. differs at the pragmatic level.)
Names rely on the existance of common semantics,
numbers on form agreement (isomorphism)
(Both only implied in practise most of the time,
but hey! this is cd/t/ :-)
This choice goes well beyond syntax.
> One or the other, they have the exactly same
> computational power, although they require substantially different
> syntax to express the same things.
>
> But wanting to have both at the same time, while it seems innocuous
> enough, actually leads to the loss of important algebraic properties.
> It seems like it can be reconciled, but I am convinced it can't, at
> least not without some loss.
Intuitively: Yep, I think it can't either. My guess: demarcating
this loss will take some effort and time, though.
> (This is not to say that you can't have some *separate* numeric-to-
> name mapping, or multiple such, and use one in one context and
> another in another; there's nothing wrong with that. The problem
> comes in trying to have the mapping be part of the value, or part
> of the type.)
That is where semantics and the (human) ease of names kick in.
> For example, if one has some relations R[a,b] and S[b,c],
> (here, use of [] indicates the attributes are ordered) and
> one does a natural join, what shall be the order of the resulting
> columns? If the proposal is R join S has columns, in order, [a,b,c],
> then that means that S join R would have column [c,b,a], which
> would mean that natural join would no longer be commutative.
> You can try to escape by proposing that the order of the columns
> not be relevant in determining equality, but then that breaks
> substitutibility.
>
> I'm too tired to write up the substitutibility problem right now.
> I'll just mention that I spent long time trying to devise a
> syntax and semantics that would hold all the design value
> of named attributes with all the notational convenience of
> positional attributes, and I couldn't make it work. The
> problems are subtle, but pernicious.
I wish I had some nice words to encourage you to share
those problems.
David Cressey
"mAsterdam" <mAst...@vrijdag.org> wrote in message
news:4437030e$0$11073$e4fe...@news.xs4all.nl...
>
> As soon as it does change (e.g. add/scratch an
> attribute/column/field/whatever horizontal thingy)
> the /number/ references have to be re-examined whereas the /name/
> simply continues to refer to the correct (as
> correct as it was to begin with) data.
>
The above is true if the numbers are determined by a position in a list. If
the numbers are simply assigned
sequentially, as if they were "names", you could alter relational tables
or relations without regard to the
"column numbers". However, since attributes in a relation are written down
by POSITION, and not merely by numerical name, your point is valid with
regard to mathematical relations.
Going back to the original question which was (roughly) "what's the
difference, in mathematics, between a relation and a relationship", the
question you raise may not arise. I declined to offer either Codd's answer
or my own. I didn't offer Codd's because I don't know it. I didn't offer
mine because I'm not a mathematician.
All of the answers that have been since advanced do not relate to the
mathematical consequences of "relation" vis a vis "relationship". They
relate to the software engineering problems of building a DBMS, and to the
human problems of sharing data without losing meaning. These problems are
real, but they aren't "mathematical". (That's not to say that mathematics
cannot be usefully applied to addressing these problems. I'm not offering
an opinion on that, either).
What mathematicians who read Codd tend to overlook is that Codd was not
writing mathematics. He was proposing a data model. The fact that his
model maps tightly onto the mathematics of relations was part of Codd's
intention, and one of the reasons for the durability of the model. But the
purpose wasn't to advance the frontiers of mathematics. The purpose was to
advance the frontiers of the human art and the engineering discipline of
building and using large, shared data banks.
dawn
> dawn wrote:
<snip>
> > I would have to re-read things to be sure, but I thought perhaps his
> > concern was over decoupling the logical and physical model of the
> > attributes. In systems where attributes are referred by numbers, there
> > is often a correlation between the logical and physical order, although
> > there need not be.
>
> Exegesis is not my hobby. I thought it wasn't yours either.
touché
Marshall Spight
>
> This is a seemingly tiny detail, of course, but it comes up more often
> than one might guess in the RM literature as if it were problematic and
> it just doesn't seem to be in practice. I'll grant I'm not working
> with a strictly RDBMS product (but who is?)
I too have often seen this written down as being a problem. But I
haven't ever seen the supposed problem explained.
I want to be clear that I don't think that it's not feasible; it is.
It's just that it comes at a cost. You trade notational convenience
for useful algebraic properties. I haven't noticed that existing
systems care as much for those algebraic properties as they
might.
Marshall
Marshall Spight
>
> I remember that the order of the rows is also irrelevant.
> Why we name attributes with strings and we don't name the rows ? :-)
> Why not the other way around ? :-)
You smile, but it's actually an interesting question.
The columns have an identity that must be unique; there is this rule
that names identify columns.
The rows have an identity that must be unique; there is this rule
that keys identify columns.
Coincidence? Are these two examples of the same rule, just with
different key domains?
Marshall
David Cressey
"Marshall Spight" <marshal...@gmail.com> wrote in message
news:1144567187....@e56g2000cwe.googlegroups.com...
It is worth a smile.
But adding a row is data manipulation, while adding a column is data
definition. Something is radically different.
Marshall Spight
> Marshall Spight wrote:
> >
> > The choice between a numerical vs. symbolic identification of
> > attributes is purely syntactic.
>
> I can not agree with that.
>
> First a frame of reference.
> Supporting levels, low to high:
> (fatic -) syntactic - semantic - pragmatic.
I don't understand this last paragraph at all. (What is "fatic?")
But it seems to imply that syntactic is somehow "lesser"
than semantic; I wouldn't agree with that. They are different
things, but one is not "higher" than the other; both are
necessary for language.
> Numerical vs. symbolic identification of attributes has
> consequences (i.e. differs at the pragmatic level.)
I'm not sure I understand this either. It seems to say
that if something has pragmatic consequences, it can't
be purely syntactic. If so, I strongly disagree.
Syntax is huge in what it can do. I have often underestimated
its importance and its power, but I'm going to try not to
do that anymore. I'm still not clear on what the boundaries
of syntax are, but I'm working on it.
> Names rely on the existance of common semantics,
> numbers on form agreement (isomorphism)
> (Both only implied in practise most of the time,
> but hey! this is cd/t/ :-)
>
> This choice goes well beyond syntax.
Can you give a specific example?
Consider: we can write a relational language which contains
join as an operator. We can write this language in such a way
that the syntactic phase uses either numbers or names to
identify relation attributes, and we can produce an abstract
syntax tree that identifies attributes either by name or by
position.
So how is the decision anything *other* than syntactic?
> > But wanting to have both at the same time, while it seems innocuous
> > enough, actually leads to the loss of important algebraic properties.
> > It seems like it can be reconciled, but I am convinced it can't, at
> > least not without some loss.
>
> Intuitively: Yep, I think it can't either. My guess: demarcating
> this loss will take some effort and time, though.
It certainly took me long enough!
> > I'm too tired to write up the substitutibility problem right now.
> > I'll just mention that I spent long time trying to devise a
> > syntax and semantics that would hold all the design value
> > of named attributes with all the notational convenience of
> > positional attributes, and I couldn't make it work. The
> > problems are subtle, but pernicious.
>
> I wish I had some nice words to encourage you to share
> those problems.
Um, well. Let's see.
An important property of a language is that you can bind a
subexpression to a name and then rewrite the expression,
substituting the name for the subexpression and get identical
results.
Okay, I'm really going through a stupid phase. I'll have to defer
again.
Marshall
Christopher Browne
Well, this exposes that there are two quite independent ways that SQL
allows imposition of ordering.
Firstly, there's:
select c1 as cname1, c2 as cname2, ... cn as cnamen from some_relation;
This imposes a column ordering on a return set.
Secondly, there's
insert into some_relation (c1, c2, ..., cn)
values() or some consistently-ordered select
The independence of these impositions of order obviously lead to the
"surprise."
I think you'd need a special further syntax in order to allow the
ordering to become implicit.
It's not obvious to me that this is any sort of "anti-relational
failing," either. If I specify orderings in two places, I think I'd
be surprised to see the orders "magically" change.
> Anyone would think that zonk would go into zonk, blech would go into
> blech, and zork would go into zork.
I'm not sure what proportion of the population would fall into that
"anyone"...
--
(reverse (concatenate 'string "moc.liamg" "@" "enworbbc"))
http://linuxdatabases.info/info/
"Computer science is like library science -- you create a problem and
then study it." -- David Place
mAsterdam
> mAsterdam wrote:
>
>>Marshall Spight wrote:
>>
>>>The choice between a numerical vs. symbolic identification of
>>>attributes is purely syntactic.
>>
>>I can not agree with that.
>>
>>First a frame of reference.
>>Supporting levels, low to high:
>>(fatic -) syntactic - semantic - pragmatic.
>
> I don't understand this last paragraph at all. (What is "fatic?")
A theory explained in
Watzlawick, P., Beavin, J., & Jackson, D., (1967). Pragmatics of
Human Communication. W. W. Norton: New York , referenced e.g. at
http://www.uky.edu/~drlane/capstone/interpersonal/intview.htm
has a nice and simple layered reference model for
communication interactions.
I'm going to do the theory unjustice.
It is 32 years after I last read it (I never got the book
back), and I kept reshuffling the concepts in application.
Here is the gist of what's left:
0. fatic: the creation and maintenance of the communications
infrastructure: E.g. holiday cards:
"Hi, the wether is great here - how are you doing?"
The content is irrelevant: the essence of the message is the message
itself: I am here - are you there?)
1. syntax: grammars, forms, interview-style talks.
Information structure.
2. semantics: What does it mean? Generic (say dictionary-)
interpration.
Information substance.
3. pragmatics: Goals and Consequences. What is the purpose, desired
and real effect of this communication - the interpretation and
consequential action of this message in a specific context.
Information use.
Like in network protocolstacks and n-tier client-server models
the lower level is supporting the upper level: the higher level
constructs can not exist without the lower level and there
is no use for the lower level but to serve the higher level
constructs.
An example:
You find a parking ticket on your car:
fatic: Yep, the police is doing it's job.
syntax: The form they filled.
(if the police made a mistake in this aspect there is rejoice at the
pragmatic level :-)
semantic: You parked your car where it isn't allowed.
pragmatic: How zealous is the local police in cashing the
money - can I get away with it by pretending I did not see it?
but also: I'll have to reschedule my appointment because
I have to pay this at the station within 24 hours.
> But it seems to imply that syntactic is somehow "lesser"
> than semantic; I wouldn't agree with that. They are different
> things, but one is not "higher" than the other; both are
> necessary for language.
In general: agreed - That in this support-level list
syntax supports semantics doesn't in anyway mean that
syntax is lesser than semantics.
>>Numerical vs. symbolic identification of attributes has
>>consequences (i.e. differs at the pragmatic level.)
>
>
> I'm not sure I understand this either. It seems to say
> that if something has pragmatic consequences, it can't
> be purely syntactic. If so, I strongly disagree.
Emphasis: /purely/.
Whenever we can change the syntax without affecting meaning and
use, we have a purely syntactic issue.
> Syntax is huge in what it can do. I have often underestimated
> its importance and its power, but I'm going to try not to
> do that anymore. I'm still not clear on what the boundaries
> of syntax are, but I'm working on it.
I'm not saying I do know where they are.
To me to book "Pragmatics of Human Communication",
was really helpful in not having to many difficulties
with this boundary.
>>Names rely on the existance of common semantics,
>>numbers on form agreement (isomorphism)
>>(Both only implied in practise most of the time,
>>but hey! this is cd/t/ :-)
>>
>>This choice goes well beyond syntax.
>
>
> Can you give a specific example?
>
> Consider: we can write a relational language which contains
> join as an operator. We can write this language in such a way
> that the syntactic phase uses either numbers or names to
> identify relation attributes, and we can produce an abstract
> syntax tree that identifies attributes either by name or by
> position.
>
> So how is the decision anything *other* than syntactic?
In effect.
When the stuff which is joined undergoes a change, say it
looses or gets new attributes, the number references will
have to be re-examined. I'ld say that is a pragmatic effect
of the change.
The names for existing attributes will stay the same and
consequently refer to the same as they did before effortlessly,
so in that case there is no pragmatic effect.
So, this decision, while dealing with "just" syntax, does
have impact in other areas.
>>>But wanting to have both at the same time, while it seems innocuous
>>>enough, actually leads to the loss of important algebraic properties.
>>>It seems like it can be reconciled, but I am convinced it can't, at
>>>least not without some loss.
>>
>>Intuitively: Yep, I think it can't either. My guess: demarcating
>>this loss will take some effort and time, though.
>
>
> It certainly took me long enough!
>
>
>>>I'm too tired to write up the substitutibility problem right now.
>>>I'll just mention that I spent long time trying to devise a
>>>syntax and semantics that would hold all the design value
>>>of named attributes with all the notational convenience of
>>>positional attributes, and I couldn't make it work. The
>>>problems are subtle, but pernicious.
>>
>>I wish I had some nice words to encourage you to share
>>those problems.
>
>
> Um, well. Let's see.
>
> An important property of a language is that you can bind a
> subexpression to a name and then rewrite the expression,
> substituting the name for the subexpression and get identical
> results.
Sometimes context doen't matter, sometimes it does.
Is this one of the problems?
x
"Marshall Spight" <marshal...@gmail.com> wrote in message
news:1144567187....@e56g2000cwe.googlegroups.com...
> >
> > I remember that the order of the rows is also irrelevant.
> > Why we name attributes with strings and we don't name the rows ? :-)
> > Why not the other way around ? :-)
> You smile, but it's actually an interesting question.
> The columns have an identity that must be unique; there is this rule
> that names identify columns.
Do you think the attributes as defined by Chris Date are "pointers" or not
? :-)
> The rows have an identity that must be unique; there is this rule
> that keys identify columns.
Why we insist the key be of the same degree for all rows of a relation ? :-)
> Coincidence? Are these two examples of the same rule, just with
> different key domains?
How about Codd's entity domains ? :-)
x
"David Cressey" <dcre...@verizon.net> wrote in message
news:ZYNZf.133$ee6.86@trndny01...
>
> "mAsterdam" <mAst...@vrijdag.org> wrote in message
> news:4437030e$0$11073$e4fe...@news.xs4all.nl...
> > As soon as it does change (e.g. add/scratch an
> > attribute/column/field/whatever horizontal thingy)
> > the /number/ references have to be re-examined whereas the /name/
> > simply continues to refer to the correct (as
> > correct as it was to begin with) data.
> The above is true if the numbers are determined by a position in a list.
If
> the numbers are simply assigned
> sequentially, as if they were "names", you could alter relational tables
> or relations without regard to the
> "column numbers". However, since attributes in a relation are written
down
> by POSITION, and not merely by numerical name, your point is valid with
> regard to mathematical relations.
> Going back to the original question which was (roughly) "what's the
> difference, in mathematics, between a relation and a relationship", the
> question you raise may not arise. I declined to offer either Codd's
answer
> or my own. I didn't offer Codd's because I don't know it. I didn't offer
> mine because I'm not a mathematician.
Well, the question was more like: a relation with attribute names in Chris
Date style is more similar to a Codd's relation, to a relationship or to
something in between ?
> What mathematicians who read Codd tend to overlook is that Codd was not
> writing mathematics. He was proposing a data model. The fact that his
> model maps tightly onto the mathematics of relations was part of Codd's
> intention, and one of the reasons for the durability of the model. But
the
> purpose wasn't to advance the frontiers of mathematics. The purpose was
to
> advance the frontiers of the human art and the engineering discipline of
> building and using large, shared data banks.
In the ACM 1970 paper among the operators defined I have not seen the most
important one: equality even if the other operators are based on it. :-)
David Cressey
"x" <x...@not-exists.org> wrote in message news:e1dek1$vem$1...@emma.aioe.org...
Ok, this wasn't the original post, but it was a question as you asked it.
Here it is, verbatim:
x
>
> "x" <x...@not-exists.org> wrote in message news:e1dek1$vem$1...@emma.aioe.org...
> >
> > "David Cressey" <dcre...@verizon.net> wrote in message
> > news:ZYNZf.133$ee6.86@trndny01...
> > >
> > > "mAsterdam" <mAst...@vrijdag.org> wrote in message
> > > news:4437030e$0$11073$e4fe...@news.xs4all.nl...
> > Well, the question was more like: a relation with attribute names in
Chris
> > Date style is more similar to a Codd's relation, to a relationship or
to
> > something in between ?
> Ok, this wasn't the original post, but it was a question as you asked it.
> Here it is, verbatim:
> > What is the difference between a "name" and a "position" from a
> > mathematically point of view ?
Here it is, verbatim:
"What do you think is the difference between the Codd pi
(projection/permutation) operator and Chris Date rename coupled with
projection operators ?"
I know the question in the post that appeared :-) as a reply to you was the
one you said.