On Formal IS-A definition

#11

On May 5, 4:13 am, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Quote:

On May 3, 5:04 pm, paul c <toledobythe... (AT) oohay (DOT) 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.

In any case I think it's useful to have a label for when one only uses
relations with simple data types (e.g. restricting oneself to
integers, enums and strings), and perhaps using RVAs or TVAs. I have
wondered whether that's the real intention behind the Information
Principle. If so then it should be reworded, but then again I think
many if not most people here would reject it anyway.

#12

On May 4, 9:04 am, paul c <toledobythe... (AT) oohay (DOT) ac> wrote:

Quote:

Bob Badour wrote:
Reinier Post wrote:
...
I was trying to sidestep the issue of attribute (re)naming here,
because it is beside the main point of the example, which is that
according to your definition, the same relation (Herbivores)
has two different IS-A relations, one with Animals and
one with Vegetables. I know multiple inheritance in
programming languages tends to be used in just this kind
of way (with "mixin classes" for instance) but I think with
such a notion the name "IS-A" is just wrong. It's fine to have
your proposed notion but give it a different name: call it a role
or something. A Herbivore just isn't a Vegetable.

I know this is again an argument about naming, but this time
it's about the name "is a" itself.

I thought Clinton settled this whole issue already. Cigar anyone?

I think Clinton knew his silly language parsing didn't matter to the
majority of his (semi-literate) public. What puzzles me is why smart
people here spend time on such subjective fooferah and never bring up,
say, just what the Information Principle really means.

I would say IS-A is crucial because the equivalence relation on
encoded values is crucial. The subtype=subset approach provides a
very useful tool to define equality in the type system. However, I
also think it's wrong to mess with equivalence on structural types
like tuples and relations (or putting it another way to treat tuple
and relation types as nominal types). If structural types are to be
used to implement a nominal type, then I suggest that should be made
explicit (including a user defined equivalence operator).

#13

David BL wrote:

Quote:

On May 5, 4:13 am, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

On May 3, 5:04 pm, paul c <toledobythe... (AT) oohay (DOT) 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.

#14

On May 5, 2:49 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Quote:

David BL wrote:
On May 5, 4:13 am, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

On May 3, 5:04 pm, paul c <toledobythe... (AT) oohay (DOT) 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"

#15

David BL wrote:

Quote:

On May 5, 2:49 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

David BL wrote:

On May 5, 4:13 am, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

On May 3, 5:04 pm, paul c <toledobythe... (AT) oohay (DOT) 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.

#16

On May 5, 5:52 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

Quote:

David BL wrote:
On May 5, 2:49 pm, Bob Badour <bbad... (AT) pei (DOT) sympatico.ca> wrote:

David BL wrote:

On May 5, 4:13 am, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

On May 3, 5:04 pm, paul c <toledobythe... (AT) oohay (DOT) 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?

#17

On 4 mei, 22:13, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Quote:

On May 3, 5:04*pm, paul c <toledobythe... (AT) oohay (DOT) 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.

How can it be ? It precisely the IP that allows the Relational
Algebra to be a sufficient foundation for relational data
manipulation. If other structures besides relations were admitted,
relation algebra would no longer suffice.

Quote:

Presumably arithmetic principle would prevent some
from reinventing roman numerals:-)

Roman numerals are just another possible representation for numbers.
They don't prevent the numbers, represented that way, from being used
in arithmetic. Not in the same sense that relation algebra prevents
graph databases because relation algebra does not understand graphs.

#18

On May 5, 12:41*pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

Quote:

... Not in the same sense that relation algebra prevents
graph databases because relation algebra does not understand graphs.

This is very imprecise statement. I'll embark upon your typo and
suggest that relation algebra (http://en.wikipedia.org/wiki/
Relation_algebra) does exactly that. It manipulates binary relations
that are essentially adjacency matrices representing direct acyclic
graphs.

#19

"Tegiri Nenashi" <tegirinenashi (AT) gmail (DOT) com> wrote

Quote:

Given the two relations R and S, the R is a subtype of S or simply "R
is an S" (was this the source of Reinier blunder?-) iff the two
conditions hold:

1. R ^ S = R (where the ^ is natural join operation). This can be
expressed succinctly as R < S with generalized subset constraint "<".

The immediate consequence is that the attributes of S are the subset
of attributes R (formally: R ^ [] < S ^ [] where the "[]" is the
relation with empty set of attributes and empty set of tuples, aka
DUM). Then, one may add second requirement that

2. Attributes of S form a key in relation R.

My question is if the condition #2 is really necessary. Consider the
two relations:

Animals = [Name]
bear
sheep
wolf
;

Carnivores1 = [Name FavoritePrey]
bear deer
wolf sheep
;

They satisfy both conditions so that informally we say "Carnivores1"
IS-A "Animals".

Contrast this with

Animals = [Name]
bear
sheep
wolf
;

Carnivores2 = [Name Prey]
bear deer
wolf sheep
wolf deer
;

I suggest that we still have "Carnivores2" IS-A "Animals". Do you
agree?

There is a problem here. Which scheme is better?

Employees{taxid,name,startdate} KEY{taxid},
ContractEmployees{taxid,name,startdate,enddate} KEY{taxid},
ContractEmployees[taxid,name,startdate] is a subset of
Employees[taxid,name,startdate]

or

Employees{taxid,name,startdate} KEY{taxid},
ContractEmployees{taxid,enddate} KEY{taxid},
ContractEmployees[taxid] is a subset of Employees[taxid]

Clearly the second scheme is equivalent to the first with respect to
information content, so if a ContractEmployee is an Employee in the first
scheme, then it must also be in the second, but in the second scheme, the
set of attributes for Employees is not a subset of the set of attributes for
ContractEmployees. I think the effect of the foreign key constraint,
namely, that the components of the referenced tuple are effectively
'included' with the referencing tuple, must be taken into account.

#20

On 5 mei, 22:56, Tegiri Nenashi <tegirinena... (AT) gmail (DOT) com> wrote:

Quote:

On May 5, 12:41*pm, Erwin <e.sm... (AT) myonline (DOT) be> wrote:

... Not in the same sense that relation algebra prevents
graph databases because relation algebra does not understand graphs.

This is very imprecise statement. I'll embark upon your typo and
suggest that relation algebra (http://en.wikipedia.org/wiki/
Relation_algebra) does exactly that. It manipulates binary relations
that are essentially adjacency matrices representing direct acyclic
graphs.

Yes. And I know about transitive closure and the concept of
generalized transitive closure too, thank you.

The point is, the relational model supports graphs by moulding them /
casting them in a relational form that can be proven equivalent.

Or, iow : relations are sufficient to "mimic" graphs, and graphs are
not themselves an "unmissable" component of the model.

Yet iow : The IP in relationland states that all information must be
conveyed as the presence of some tuple in some relation that is the
current value of some relvar. Graph databases allow information to be
conveyed as either the presence of a node or else as the presence of
an edge. Imo, the IP is the single one principle that "proves" (note
the quotes) (a) that the relational model can be used to represent
_ANY_ information, iow that the relational model has a certain quality
of "completeness", and (b) that it allows a simpler form of
manipulation than would be possible in any model that is based on some
type of "graph algebra".

And you say this is obsolete ? Honestly, I have a hard time taking
that serious.

Another small point is that there is a school of thought which says
something about a connection between relation algebra and first order
logic, thereby excluding transitive closure as a possible operator of
RA because transitive closure requires recursion and recursion is
excluded by FOL. I don't really understand their point, or why they
are trying to make that point, because imo (generalized) transitive
closure is a sine qua non for "expressive completeness". Without
transitive closure, certain queries are provably unanswerable, and so
TC is needed. I find that statement about the link with FOL rather
vacuous for that reason.