Re: Examples of SQL anomalies?

On Jul 1, 11:19 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Rob" <rmpsf..._at_gmail.com> wrote in message
>
> You haven't coherently addressed my initial objection to your aggregate-link
> mechanism, which is that I just can't see any practical use for reifying
> descriptions of relationships.
>
I will give it a stab. Please note that this is my last post in this thread because (as JOG has pointed out), this material is not related to the OP's original request. If you wish to extend the discussion, please start another thread. I'll be on the lookout. Thanks.

1. lattice relationships

     http://www.sfdbs.com/solopages/relcardtypes.shtml .

The direct result of the reification is that 12 new "lattice" relationship types can be represented (with the A-L schema). Unlike the conventional representation of a foreign key in an entity relation (I call it PKFK), one can have an individual entity tuple as "parent" to more than one set of "child" entity tuples. With respect to the "Junction Table" (JT) representation, in it's standard form (i.e., the primary key is the composite of the two foreign keys), representing more than one individual entity tuple as "parent" to more than one set of "child" entity tuples incidentally results in the merging of the two parent-child aggregations into a single aggregation. This can be "repaired" by adding a new, non-key attribute to the Junction Table, but the representation is no longer structure independent.

Lattice relationships are characterized by one or both of the following:
a. more than one independent aggregation with the same parent b. an aggregation with more than one occurence of the same child.

What is the value of these lattice relationships? I haven't had the time to explore this in depth. There is a simple example in

     http://www.sfdbs.com/toplevel/fasttrack/fasttrack.shtml . Wrt lattice relationships, I have only presented a new *technology*, not yet a *solution* to any known problem.

2. simplification

A side-effect of reification in the Aggregate-Link schema is the ability to represent every relationship cardinality of both the PKFK and JT representations: One representation instead of two. From an engineering perspective, simplification without loss of capability is generally advantageous.

Consider a time in the not-too-distant future in which a higher-level machine intelligence (HLMI) uses a relational database engine (RDBME) as an embedded component. For example, the HLMI may encounter a large mass of data that it needs to analyze. We'll suppose further that it understands the basics of entities and relationships.

In order to use the RDBME, it (at least) has to define the database schema (a set of relation schemas), populate them and query them. Intuitively, the simplification of "one relationship represention vs. PKFK&JT" implies that database schema design and query formulation are simpler.

Not practical enough?
- Automated data mining will be upon us in less than 10 years. Would you rather see such systems utilize proprietary data representations or use relational technology?
- Automated forensic database analysis is already under development. Again, as database specialists, would we prefer they use proprietary data representations or relational?

All the best, Rob Received on Tue Jul 01 2008 - 21:39:00 CEST