Re: "relationships" in ISO SQL Standard (was: Interesting article...)
Date: Fri, 07 Apr 2006 05:25:11 GMT
Message-ID: <XImZf.565$An2.22_at_newsread2.news.pas.earthlink.net>
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.
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>
- 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...
-- Jonathan Leffler #include <disclaimer.h> Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com Guardian of DBD::Informix v2005.02 -- http://dbi.perl.org/Received on Fri Apr 07 2006 - 07:25:11 CEST