Re: On Formal IS-A definition

On May 5, 5:52 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> David BL wrote:
> > On May 5, 2:49 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> >>David BL wrote:
>
> >>>On May 5, 4:13 am, Tegiri Nenashi <tegirinena..._at_gmail.com> wrote:
>
> >>>>On May 3, 5:04 pm, paul c <toledobythe..._at_oohay.ac> wrote:
>
> >>>>>... and never bring up,
> >>>>>say, just what the Information Principle really means.
>
> >>>>..."the entire information content of the database is represented in
> >>>>one and only one way. Namely as explicit values in column positions
> >>>>(attributes) and rows in relations (tuples)."?
>
> >>>>It is obsolete.
>
> >>>>Seriously, I think it is aimed at cowboys who try to invent new data
> >>>>management systems without studying what relational model is about. It
> >>>>is about attributes and tuples because both relational calculus, and
> >>>>algebra explicitly refer to relations structured this way. The
> >>>>situation is similar to arithmetic where pupils learn how to add/
> >>>>multiply numbers represented in a very specific notation. So the
> >>>>arithmetic principle would say ..."the entire content of arithmetic is
> >>>>represented in one and only one way. Namely as explicit sequences of
> >>>>digits in numbers". Presumably arithmetic principle would prevent some
>
> >>>>from reinventing roman numerals:-)
>
> >>>I agree. My own take on the Information Principle is that "one and
> >>>only one way" is misleading because one generally has a choice of
> >>>whether to use rich or simple domain types. One could represent the
> >>>entire database value in a single relation containing a single tuple
> >>>with a single attribute and be adhering to the Information
> >>>Principle. In that sense it seems rather vacuous.
>
> >>I disagree that it's vacuous. Even in this situation, the principle
> >>prohibits physical pointers in the logical structure.
>
> > Excellent point.
>
> > Actually I wonder if it could even be said to be too restrictive.
> > What if I want the entire database value to have a nominative type?
> > This allows me to give the database a formal semantic (i.e.
> > interpretation) that's explicit. E.g. my entire database might
> > represent a complex 3D shape.
>
> > Just as nominative types are necessary for supporting the definition
> > of structural types, I think structural types are useful for
> > implementing user-defined nominal types. Nominative and structural
> > types are both fundamental and it seems arbitrary to force one not the
> > other to be "at the top" of the database.
>
> > So I suggest the Information Principle should be:
>
> > "the database records a value"
>
> That would be vacuous because every database records a value regardless
> of logical data model.

I thought it wasn't vacuous to the extent that abstract mathematical values are always defined by axiomatic systems without reference to a physical implementation that exists in time and space. Therefore this principle implies some degree of separation of concerns. Obviously physical pointers are prohibited in the level of discourse of the abstract value itself (i.e. in the algebraic system).

For example, the principle implies one doesn't think of the database as recording a consistent cut of an executing state machine. Indeed this has been tried many times but has never been practical. E.g. The Grasshopper OS - see http://os.dcs.st-and.ac.uk/GH/. I admit that one could subvert the principle by regarding a consistent cut of a state machine as a value, so I suggest that the principle be taken to mean that the *purpose* of the database is to record an abstract mathematical value. From a practical point of view the state identified by a consistent cut has a very direct relationship to the physical implementation, making it horribly complex. That's before talking about the ultimate show stopper for orthogonal persistence: schema evolution. How does one evolve a process while it is running? Received on Wed May 05 2010 - 15:35:52 CEST