Re: Examples of SQL anomalies?

"Rob" <rmpsfdbs_at_gmail.com> wrote in message news:bac468ba-762a-4a41-a342-e976d45a14a6_at_y22g2000prd.googlegroups.com...
> 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
>
> These are described more fully in
> 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
>
>

You appear to be equating descriptions of relationships with relationships. You also appear to be stuck in the world of E-R. Instead of further criticizing what you consider to be a new "technology," I am going to suggest some reading:

"Justification for Inclusion Dependency Normal Form," Levene and Vincent, 2000
"Horn Clauses and Database Dependencies," Fagin, 1982 Zalta's Theory of Abstract Objects: http://mally.stanford.edu/theory.html Received on Wed Jul 02 2008 - 05:05:06 CEST