Re: types vs. views

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:Smp5b.17$eu1.222_at_news.oracle.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:cd3b3cf.0309030652.27cfaff1_at_posting.google.com...
> > "Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message
> news:<irr3b.16$D94.166_at_news.oracle.com>...
> > > When quering how many circle center points are positioned in
> > > vicinity of some point, for example, we would like to know Polar
> coordinates
> > > for all the tuples, no matter what internal representations they have.
> >
> > The type system in TTM allows (even encourages) this. The DBA might
> > specify a polar physical representation, but this doesn't matter
> > because the dbms can derive the desired representation from any
> > physical representation.
>
> How DBMS would derive the desired representation? Is
>
> TYPE POINT
> POSSREP XY_POINT { X NUMERIC, Y NUMERIC }
> POSSREP POLAR_POINT { A NUMERIC, R NUMERIC }
>
> a valid syntax? Now
>
> POINT P := XY_POINT (1,1)
>
> NUMERIC ANGLE := THE_A(P)
>
> would the last operation succeed or throw an exception? In other words,
when
> specifying N possreps for a type is DBA also required to write doen
N*(N-1)
> conversion operators?

No, the DBA can choose one of the declared possible representations as a reference representation and write 2*(N-1) conversions. One conversion from each of the other possible representations to the reference representation and vice versa. Of course, nothing prevents the DBA from writing additional conversions for reasons of performance etc.

The dbms can derive any of the other conversions by nesting a conversion to the reference representation inside a conversion to the target representation.

Actually, theoretically, the DBA could write N conversions in a ring but then the dbms might have to evaluate N-1 nested conversions to derive each inverse conversion. One could think up any number of graphs and let the dbms solve the shortest path problem, but I have no problem with the dbms implementation requiring 2*(N-1) conversions.

> > > Both queries could be answered if we have
> > > 2 views CartesianPointCircleCenter and PolarPointCircleCenter and just
a
> > > single representation for the Point.
> >
> > This is a straw man. You have already remarked on the updatability
> > problem this causes and that the type system in TTM solves.
>
> Once again, if manually programmed conversion operators are part of TTM,

The conversion from logical to physical must be specified somewhere. However, involving the physical takes the subject beyond the scope of TTM, which specifies the logical model.

> then the TTM possrep conversion idea is similar to "on update" trigger
where
> DBA must code view updates.

I never claimed anything different. However, the DBA need only write the conversions once for the domain and the dbms can apply them to any view.

Your original point still stands because not all operations are possible representation operations and the dbms may have no convenient inverse. I only pointed out that the type system in TTM effectively reduces the occurance of the problem without fully eliminating it.

> > > I can't possibly see the
> > > benefit of having heterogeneous list of Points in the database design.
> >
> > At the logical level, there is no heterogeneous list. Whether it is
> > heterogeneous at the physical level is irrelevant to expressibility
> > and affects only performance.
>
> OK.
>
> > I am not implying anything that isn't stated explicitly in TTM. There
> > are no "getter" or "setter" methods in TTM. Getting and setting
> > focuses on the physical location of variables and not on the logical
> > meaning of values.
>
> Question. Are observer methods on logical or physical level?

All operations specify a public interface and have a private implementation. Because the implementation is private, whether the implementation references the physical level or the logical level is irrelevant to all but the implementer and the security function. Actually, to be exact, the privacy of the implementation is likewise a matter for the security function. Received on Wed Sep 03 2003 - 19:51:31 CEST