Re: Storing data and code in a Db with LISP-like interface

> Look at the RM/T paper in the section about aggregations.

While searching, I ran across a few remarks:

Chris Date "As far as I know, neither Codd nor anybody else ever did much to follow up on the original (1979) RM/T paper. The informal RM/T classification of entities into ernels, characteristics, and associations is helpful, at least from an intuitive point of view. But, frankly, I don't think the RM/T notions of generalization, cover aggregation, and event precedence were ever very clear, and--as I've already indicated--they haven't been elaborated since, so far as I know. The same is true of the RM/T operators as well. What's more, the RM/T paper was the first in which Codd seriously advocated the use of NULLs and three-valued logic, and--along with many others--I've been opposed to those ideas for many years!"

By Simon Williams "Codd goes on to describe an extended version of the relational model called RM/T in an attempt to capture more of the meaning of the data by embracing concepts dealing with molecular semantics such as aggregation and generalisation. Codd later refines RM/T into RM/V2, which comprises 333 features."

"The extended relational model was developed by Codd and Date using the same formal methods as the relational model. The extended model incorporates semantic information by categorizing entities and their corresponding relations, by including a form of abstraction, and by providing general integrity constraints. The model works as follows: A relationship is regarded merely as a special kind of entity. Entities (of all kinds) are represented by E-relations and P-relations, both of which are special forms of the general n-ary relation; E-relation are used to record the fact that entities exist, and P-relation are used to record certain properties of those entities. RM/T also maintains an Entity Hierarchy."

"The basic idea is as follows. When the user creates a new entity representative in the database - e.g., when the user issues the SQL statement
INSERT INTO Student (S#, STU-Name, Major, Credit) VALUES ('S1001', 'Smith Tom', 'History', '90'); the system generates a new surrogate value for the new entity (Student S1001). The value is unique with respect to all surrogate values that exist or ever have existed in the database; furthermore, it is guaranteed never to change. All references inside the system to Student S1001 will be via its surrogate value."

Looks interesting. I'll have to think about it. Thanks. Received on Thu Apr 20 2006 - 00:32:17 CEST