Re: Units of Measurement in the Database Model

From: Chowdary <ps_chowdary_at_hotmail.com>
Date: Fri, 07 Jun 2002 13:43:56 GMT
Message-ID: <wM2M8.34443$092.1024211_at_news1.east.cox.net>


Thanks all for lively discussions on UOM.

UOM is a classic problem/requirement solved by different companies in different ways suitable for their products.

Instead of reinventing the wheel, we may look at some of the implementation in some enterprise software products like SAP, ORACLE apps, PeopleSoft, Siebel.... to have more clear understanding of usage of UOM more efficiently.

Can someone pl come forward and share their design experiences in these s/w companies?

In my opinion,

  1. For UOM requirement of column level, option #3 is very suitable.
  2. For UOM requirement upto row level, option #4 looks to be more appropriate.

A combination of these two may be used to have a very good system.

We may add check constraints so that we can limit scope of a UOM for each column. Suppose we wanted to have only cm, mt, ft and in in a length column, then it is better to add a check constraint to limit to these values.

Some systems maintain internal base unit but this can lead to rounding errors again. So it may be better to leave base unit definition to user and convert all the units into base unit, while using the data.

thanks,
Srinivas

"James" <jraustin1_at_hotmail.com> wrote in message news:a6e74506.0205301239.68fb0b3d_at_posting.google.com...
> > From original poster:
> > How should the database be organized in regards to measurements
recorded,
> > and the units of measurement (UOM) used to record them?
>
> I am not suggesting to use an oodb solution but it may shed light on
> the appropriate rdb solution.
>
> In XDb each "value" is actually an object.
> Each "value" (ie 130, 180) is an instance of a class (ie Weight) or
> its descendant sub classes. The base class can define a default UOM as
> a static property. A static (as opposed to a virtual) property does
> not propagate with instances of Weight. Any sub class or instance can
> override the default by having a UOM property.
>
> Implementation would be:
>
> Classes
> ------------
> UOM
>
> Weight
> .UOM - lb // Static property of weight
>
>
> Instances
> ------------
> UomInstsFldr
> lb
> kg
>
> WeightInstsFldr
> 130 // Inherits UOM = lb as defined in class
> 180
> .UOM - kg // Overrides default UOM defined in Class
>
>
> Thus,
> 130.Prop_get(UOM) returns 'lb'. 130 inherits the default UOM defined
> in its class.
> 180.Prop_get(UOM) returns 'kg'. 180's UOM overrides that defined in
> its class.
>
> It is also possible to define as such
>
> Classes
> ----------------------
> System
>
> UOM
> .System = Unknown
>
>
> Instances
> -----------------------
> System
> Unknown
> English
> Metric
>
> UomFldr
> lb
> .System = English
> kg
> .System = Metric
>
> Thus,
> (130.Prop_get(UOM)).Prop_get(System) returns 'English'
> (180.Prop_get(UOM)).Prop_get(System) returns 'Metric'
>
> Above implementation is described more visually at
> www.xdb1.com/Basics/UOM.asp
>
> Also see www.xdb1.com/Dev/API/Obj/Prop_get.asp &
> ww.xdb1.com/Basics/Property.asp
Received on Fri Jun 07 2002 - 15:43:56 CEST

Original text of this message