Re: Domain Definition

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:<qpoT9.23$L43.157_at_news.oracle.com>...
> Mixing units is bad idea anyway. This is why scientific community adopted
> standartization. If metric system is fixed, then there is no cofusion on the
> "semantics" of a given number.

   Mixing units is a tremendously bad idea. But the fact is, it's done, and   when the fact that it is done is not recognized and dealt with, disaster   follows.

    o September 1999, NASA loses a $125 Million Mars Climate Orbiter

      probe because one software team thought Newtons, the other 
      pounds per aquare foot.

    o Every XML standard I've seen where 'weights and measures' were 
      important has elected to include 'UNIT' as an element (and it's 
      sometimes marked as 'optional'!).

   Global standardization of everything would be lovely, but in the short term   it's also completely impractical. I mean, are you going to pursuade the US to   adopt metric measurements? And if so, are you going to pursuade builders   and surveyors and civil engineers that every measurement of length that they   make must be recorded in millimeters (rather than centimeters, meters, or   kilometers)?

> Why do people agree that normalizing data schema is a good thing, while feel
> that requirement to store measurements in the same system is somehow too
> limited? Standartization just improves the quality of your data, similar to
> what normalization does!

    I agree. And in a sense, what the domain concept allows you to do is    to derive the same benefit (standardization) without engaging in a    futile attempt to get all application developers, end users, business    managers and other stake-holders to agree on the unit. Shoot - they    don't even concur on syntax. It's hard enough getting them to agree on    the name of a SQL table or column!

    Besides: in addition to units, the semantics of a physical measurement    (empirical quantity) includes other things, such as the notion of error,    and precision. Even if we all adopted a standard unit you'll still find that    mathematics over measurements needs standardization.    

> The domain idea looks like a kludgy attempt to fit the data into some unit
> system. It doesn't really care about the quality of the unit system.

     Well, domains are a *lot* more than 'fitting data into some unit system'.     I think we may have a 'not seeing the wood for the trees' type issue.

     But by your argument, why not just have one domain 'BITVECTOR(N)'? All of     the SQL types are just 'kludgy attempts to fit data'? (This isn't a bad     thing, BTW: in languages like LISP, *values* have type, *variables* do     not. You could think of a DBMS where the values stored are all     self-describing. Wierd, but it would be consistent).  

> In general, isn't the whole domain concept backward? People were
> manipulating quantities since the dark ages and generalized quantity idea as
> a number. The domain concept would never lifted them to grasp a simple idea
> that adding 3 apples and 3 oranges results in 6 fruits.

    The 'domain' idea is central to the whole relational model as it is to    the logical model it derives from! And it's utility goes *way* beyond    questions about units/measure/error. If you like, it's a way of abstracting    the physical representation of an atomic value from presentation and    manipulation.

    Domains aren't as simple as you seem to think. (And this is one of the    additional challenges I was talking about in the last post.)

    Let's stick to numbers. Take SQL integers. Contrast them with (say)    LISP integers. SQL INTEGERS have fixed length representations. LISP    integers have arbitrary precision. Now, if you divide one mathematical integer    by another, what do you get? Sometimes, you get an integer but most often    you get a rational number. SQL doesn't have a RATIONAL type (and its hard to    see how you would get one to work using the SQL-92 domain support) so the    language standardizes how SQL numbers inter-operate: it specifies    (standardizes) how operations on types/domains behave.

     There is no reason why an application developer couldn't impose whatever    semantics they want over fruit at the data management level. '6 ORANGES' +    '7 ORANGES' = '13 ORANGES'. '6 ORANGES' + '7 BANANAS' = '13 FRUIT'. You'd    still need a set of domain specific operators -- EQUALS, for example, so    that you could create a relation with a 'FRUIT' domain attribute in the    key, which begs the question whether '6 ORANGES' = '6 FRUIT' or not -- but    the whole concept fits seamlessly into the relational edifice.

     But the motivation for domains in [SQL|R|OR]DBMSs comes from the way    that it allows the schema to better model the business problem, and therefore    allows the DBMS to provide better application support. For example, there    are any number of useful mathematical tools or concepts that SQL doesn't    support directly, many of which are domain specific: alternative calenders,    yield curves, linear algebra, graphs, etc. SQL *can* be used to program    these situations (just as assembler can) but the thinking is that by    enriching the DBMS's library of domains/types you'd get the same kind of    productivity and quality improvements you got with procedural programming.

     KR

                Pb