Re: A Normalization Question

> > How to represent '(john take final) cause (john receive 95)' in RM?
>
> T_SVO
> -----------------------------------
> ID Subject Verb Object
> thingA 'john' 'take' 'final
> thingB 'john' 'receive' '95'
> thingC ->thingA 'cause' ->thingB

Is the above allowed by RM? Can an attribute (ie Subject) have both "scalar values" and references?

Also, the above table indicates a person named 'john'. Name is an attribute of the person. How would one normalize that attribute so that changing it from 'john' to 'nhoj' would not result in an update anomaly?

> and the table above is normalized in the sense that it contains no logical
> redundancy (please note the careful use of the word "logical") there is
> no row or column in the table that can be computed given the other rows
> or columns.)

While the above table may contain no redundancy within RM's limited scope/definitions, there are redundant things including the string 'john' which names a person and redundant symbols. That string 'john' is redundant can be shown by the update anomaly that occurs by changing one of the string 'john' to 'nohj'. That symbol 'j' is redundant can be shown by the update anomaly that would occur if one could change a 'j's attribute (ie its ascii). Neither anomaly occurs in XDb2/TM as there is only one string 'john' and one symbol 'j' in a db representing the above. See www.xdb2.com/Basic/Name.asp, www.xdb2.com/Example/ThingsNamedBrown.asp and www.xdb2.com/Example/StudentActivityScore.asp

> > Unlike RM, where values of a column can only reference tuples of a
> > single relation determined at design time, in XDb2/TM, any thing can
> > reference anything in the entire db at run time.
>
> So XDb2/TM cannot admit static type checking. Many of us in the
> declarative programming community would see that as a serious problem,
> both practically and logically.

At the db engine level, there is no need for type checking because everything is a thing. The db engine is happy to relate 'john color blue', 'john color steel', john color book' etc. At the lowest level, it is not a db engine's business to decide which relationships are acceptable. XDb2/TM places the burden of type checking upon the application. For example, in the standard GUI, the drop-down list in a cell containing blue, only shows other colors, but NLI allows user to relate john's color to a book. Such flexible typing becomes more useful in AI-type apps. It is similar to humans expressing "it hit me like a locomotive" or "sky was on fire". Received on Mon Jul 26 2004 - 20:37:08 CEST