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

On 26 May 2004 11:35:43 -0700, Neo wrote:

>> > Another isssue with the provided implementation is that
>> > the class hierarchy is not modelled faithfully.
>>
>> You obviously didn't check my model too well.
>
>My apologies. Because I was trying to limit the complexity of
>understanding the provided solution, I had removed tables (T_Types and
>T_Attribs) from the script that were not being accessed to generate
>the report. And when looking thru the abridged script, I could only
>conclude (wrongly) that the class hierarchy was simply encoded in the
>table named things since I didn't find it in the expected hierarchies
>table.
>
>However, after looking thru the original script, I find the following
>lack of genericness and normalization.
>
>1. A minor (but crucial) point. The data in types table does not
>encode the class of force, church, person, dog and computer which
>should be thing. Probably the reason it didn't is because there is
>(correctly) no record for thing in things table and RM doesn't provide
>a way to reference a table, only records in a table (XDb1 is different
>in this respect, it can in effect, reference a record or a table
>equally). While some might say, it is implicit that person isa thing,
>I would say this is failure to properly model the relationship between
>data. In the provided solution, the method used to get the class of
>john does not work to get the class of person. In XDb1,
>T_Ref_Xth(pAnyThing, rCls) provides a systematic method to determine
>the classes of any thing.

This reminds me of an assignment my classmates and I had in class. We were given some sample population statistics from Rotterdam (a Dutch town) and we were asked to model a database to be used by the Rotterdam town council to store that data for the last several years past and future years. Many students included a columnn "Town", to store the town name Rotterdam. Some even included a table "Towns".

The teacher told us this was wrong. *ALL* data that would ever be stored in this database was about Rotterdam. Everybody using this database would be working in the Rotterdam city council, expecting to get data about Rotterdam. Explicitly storing "Rotterdam" (or even an integer pointing to the one and only row in the towns table) would be redundant.

In your original post (with classes only, no subclasses), storing that each class is a thing would be redundant. Even with subclasses, one might still consider it redundant. But since your original message had no hint towards subclasses, that's a moot point anyway.

>2. Because the procedure which creates the report utilizes hierarchies
>table (and not the types table), it is impossible to create a nearest
>common ancestor report for the class hierarchy (without adding
>redundant data). In XDb1, because all hierarchies are encoded
>similarly, the procedure which creates the report handles the class
>hierarchy the same as any other.

This is irrelevant, since tour original post had no mention of a class hierarchy. My entry for the challenge is based in that post, not on things you might have intended to write at that time, but didn't.

>3. But more importantly and fundamentally, encoding the class
>hierarchy in tables other than the hierarchies table is
>redundant/unnormalized.

This is irrelevant, since tour original post had no mention of a class hierarchy. My entry for the challenge is based in that post, not on things you might have intended to write at that time, but didn't.

Best, Hugo

-- 

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