Re: Examples of SQL anomalies?

On Jul 1, 8:39 pm, Rob <rmpsf..._at_gmail.com> wrote:
> On Jul 1, 11:19 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:> "Rob" <rmpsf...@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.

No personal offence was intended. I have just become very frustrated at the level of bot spam on cdt without the user generated kind appearing too. I still maintain hope that you will eventually recognize that your method of adding values not in the original data to create your "aggregates" is deleterious.

>
> 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
Received on Wed Jul 02 2008 - 01:45:17 CEST