Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)

On 26 May 2004 14:09:45 -0700, Neo wrote:

>> > Actually the provided solution is inconsistent in that the class
>> > hierarchy of things ... isn't encoded in the hierarchies table.
>> > It is instead encoded in a dedicated table named types.
>>
>> Yes, indeed. That's because I normalized the data (as requested in the
>> original message). Note: see my other message as well, where I provide an
>> additional table to keep track of the class hierarchy.
>
>Even structure is data. The structure to store all hierarchies needs
>to be normalized. In the provided solution, the leader hierarchy is
>stored in the hierarchies table, as expected. But the class hierarchy
>is stored in types tables (which makes that hierarchy inaccessible to
>the procedure that generates the report). The fact that hierarchies
>are stored in two different tables is redundant/unnormalized.

See the message that I posted before this one.

> For
>example, in XDb1, if user right clicks the tree root node labeled
>'thing' (which is the root of the class hierarchy), the nearest common
>ancestor class report is generated.

Yes indeed. And it looks like this:

Common Ancestor Report for 'thing'
ThingX ThingY CmnAnc Dist
Time elapsed: 15 msec

Wow! I'm impressed. 15 msec to produce ... nothing!!

>> > The procedure that generates the report utilize hierarchies table
>> > and not the types table.
>>
>> Of course. If you'd replace the statement 'john isa person' by 'john isa
>> dog' but leave all 'xxx leader yy' statements intact, the Common Ancestor
>> Report would remain unchanged.
>
>I think, you may be assumming I still want the nearest common ancestor
>leader among things. I want the nearest common ancestor class among
>things. How can I do that with the provided solution without the db
>having redundant data?

See the message that I posted before this one.

Best, Hugo

-- 

(Remove _NO_ and _SPAM_ to get my e-mail address)