John, Pat C, Pat H, Matthew: (01)
PC> In the RDB's I have seen, each field (column in a table) often
> (typically?) represents one relation on the type represented by
> the table, so the number of columns does not have any relation
> to the arity of the relations used. (02)
[JS] That would be a variation of #1 above. A column labeled Manager,
for example, would represent a monadic predicate that is true of
each of the individuals named by the character strings in that
column. However, none of the SQL operators do anything to support
or enforce any such typing. For example, you would like to say
that Manager is a subtype of Employee, and Employee is a subtype
of Person. But those constraints would not be enforced by SQL. (03)
[JS] Ted Codd, Chris Date, and others published various proposals for
adding types, type hierarchies, and type constraints to relational
DBs, but they weren't adopted in the standards for SQL. (04)
[RC] Actually, SQL enforces foreign key constraints that let the modeler:
1. require that the value of each (Employee table row, Manager column)
entry be equal to (some key row of the Manager table);
2. require that each (Employee table row's key column), and each
(Manager table row's key column), be equal to a key column in (some row of
the Person table);
3. require that each (Manager table row's key column) be equal to a key
column in (some row of the Employee table);
4. require that Employees be defined before Managers can be designated;
5. require that Person(s) be defined before Employees can be
designated. (05)
[RC] These requirements are type constraints. In effect, those foreign key
constraints specify that both Employees and Managers must be Person(s), and
that each Manager must be an Employee. These requirements:
1. provide effective type designations of Employees and Managers;
2. require that IsA(Manager, Employee) and IsA(Employee, Person). (06)
<snip/> (07)
[JS] As Matthew points out (see below), it is
generally more efficient to combine multiple tables with few
columns into a smaller number of large tables with multiple columns. (08)
MH>> Are you saying that most of the table schemas you see in rdb's
>> have large numbers of fields because they were purposefully
>> re-engineered that way (from collections of binary relations)
>> in order to make access (and joins) more efficient? (09)
[RC] Yes. Most real world DBs use third normal form for exactly that
reason. But sometimes, denormalized tables are preferable for performance
reasons - not for conceptual modeling reasons. (010)
-Rich (011)
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com (012)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (013)
|