Very simple question to relational theorists.

[Evgeniy Grigoriev]

Suppose I’ve created a number of normal relations.... Then I use only
relational algebra operations on these relations to get new relational
values which are possible presented in virtual relations. Also in all
these operations I use RENAME operator on attribute names to rename
them according to some special rules. The new attribute names of the
virtual relations are complex enough (e.g. “details of bills”) and can
contain a dot inside (e.g. “bills.details”)

Is this system the relational one?

[Roy Hann]

Based (only) on your description it can't not be.

--
Roy

[Evgeniy Grigoriev]

Thank you. I think the same.

But is a way of how I create the normal relations important? Suppose a part of system exists which creates the relations according to some external non-normar expression descrided some data. In other words this part of system translates external expression into commands which create a set of normal relations. So user of such system gives to the system some non-normal data description expressions but operates with the data presented in form of normal virtual relations only.

(once again - all data are presented for user in form of normal relations)

The attribute names of these relations are complex enough and can contain a dot inside (e.g. “details.amount”). These complex attribute names are build according to income data description.

[Bob Badour]

Be careful: "some special rules" is handwavy enough that it could mean
anything--including exposing physical details.

[Evgeniy Grigoriev]

пятница, 4 мая 2012 г., 23:28:21 UTC+4 пользователь Bob Badour написал:

> On 5/4/2012 2:01 AM, Roy Hann wrote:
>
> Be careful: "some special rules" is handwavy enough that it could mean
>
> anything--including exposing physical details.

I'm not sure if this rule includes exposing physical details.

Suppose there are two normal relation in a system, which contain headers and lines of some documents (don't ask me about dots in front of name of attributes... I can name the attributes as I wish).

(1) DOC ( ID , .No , .Date , ...) //ID is pkey, No is a pkey too

and

(2) DOC.Lines ( ID , .Item , .Qty , ...) //Pair ID, Item is pkey.

I can create next virtual relation JOINed (1) and (2) by ID and RENAMEd sone attributes

(1+2) 'DOC(ID, .No, .Lines.Item , .Items,Qty)

At that all combinations (header_name + attribute_name) are the same in (1),(2) and (1+2) (...almost same ;), e.g. combination which gives name sequence Doc.Lines.Item. I keep a name sequences unchangeble.

This is my main rule.

Is such system relational?

I'm asking about this because it seems that I use reference constructions and all these dots seem to be the "physical details" you are speaking about. But in fact it's just play with names which is performed by RENAME operation.

[com...@hotmail.com]

On Friday, August 17, 2012 8:37:23 AM UTC-7, Evgeniy Grigoriev wrote:
> On 5/4/2012 2:01 AM, Roy Hann wrote:
>> Be careful: "some special rules" is handwavy enough that it could mean
>> anything--including exposing physical details.

> Is such system relational?
> I'm asking about this because it seems that I use reference constructions and all these dots seem to be the "physical details" you are speaking about. But in fact it's just play with names which is performed by RENAME operation.

When you started this thread I looked at some papers of yours in the arxiv and if that's the technique you're using, you are not being relational. You are just using multiple relation variables as a data structure and you are including values that act as pointers into the data structure by encoding locations in it.

To be relational a DBA must associate with every relation variable a predicate about the world that each of its present tuples makes true and each of its absent tuples makes false. It must map a tuple and a world situation to a truth value. With those pointers being there, if you tried to write predicates you would find that you have to mention relation variable names as further parameters. So you would not be giving predicates. You would be giving simultaneous equations whose unknowns were relation variable names, to be solved for valid relation variable values.

These equations would happen to form constraints for valid data structure values. But you can't use(update or query) the data structure relationally because you don't have predicates to tell you what the relation variable names in queries mean, and thus what the queries mean. Of course you can use relation operators to manipulate relation variables of your data structure just like you can use any operators to manipulate variables of any types. But that's not querying about the world.

Indeed you won't have told the user how to use (update and query) your data structure to describe a world.

And you need special operators to manipulate your data structure reasonably. These will be partly describable/implementable in terms of relation operators but also pointer encoding/decoding operators. Yes occasionally a special operator on some arguments can be implemented exactly as a relation operator on the same arguments but this is rare and incidental. When you are using relation operators in expressions that should be special operator calls that is the implementation/representation/"physical" leaking out. (Ironically this lower level is itself relations. Though not relational.)

As to your particular messages in this thread, you are not describing what you are doing clearly enough for us to give you an answer. You can't just write something that is consistent with your system. You have to write something that defines it to us.

philip

[Evgeniy Grigoriev]

пятница, 17 августа 2012 г., 23:34:50 UTC+4 пользователь (неизвестно) написал:

Thank you for answer. Let me start from the end of your message.

1) About this thread. Here I just want to show that I can use such complex names to name relational attributes.

2) I don't understand your remark about "special" operator. As I understand I can use any copmplex name to denote relation and any copmplex names to denote its attributes. This complexity means nothing for how this relation can be used. From the viewpoint of the formal relational data model, all these complex names are equal to names used to denote abstract relation R(a1, a2…). So usual relational opertion can be used, nothing special.

3) About predicates and what I must associate with relation. Relational data model is abstract mathematics. Relation is a formal and meaningless data structure. If a data structure is equal to formal definition of a relation (I prefer to use the one given in "The Theory Of Relational Database" by David Maier) it is a relation. Relation doesn't have to tell something to DBA about the world to be relation. It's not only my viewpoint (http://www.dbdebunk.blogspot.com/2012/07/meaning-and-database-management.html#more)

4) About my papers. I have another ones on ODBMS.ORG where the experimental system is described where this simple rule is implemented fully. But in this thread I want to show that dot in the name is just a part of name. Just a character. Nothing more. (Anyway, thank you very much that you read my paper :) )

By the way, from my viewpoint the relation

(1+2) 'DOC(ID, .No, .Lines.Item , .Items,Qty)

is full of sence.

[Roy Hann]

com...@hotmail.com wrote:

> On Friday, August 17, 2012 8:37:23 AM UTC-7, Evgeniy Grigoriev wrote:
>> On 5/4/2012 2:01 AM, Roy Hann wrote:
>>> Be careful: "some special rules" is handwavy enough that it could mean
>>> anything--including exposing physical details.
>> Is such system relational?
>> I'm asking about this because it seems that I use reference constructions
>> and all these dots seem to be the "physical details" you are speaking
about. But in fact it's just play with names which is performed by RENAME operation.

Just for the record, someone's newsreader is attributing comments to me
when posting follow-ups.

I do remember making some comment on this thread months ago but nothing
quoted here was ever written by me.

--
Roy

[com...@hotmail.com]

On Friday, August 17, 2012 5:04:58 PM UTC-7, Roy Hann wrote:
> I do remember making some comment on this thread months ago but nothing
> quoted here was ever written by me.

My apologies, the quote is from Bob Badour. (I repeated a misattribution to you.)
philip

[Bob Badour]

On 8/17/2012 4:14 PM, Evgeniy Grigoriev wrote:
> пятница, 17 августа 2012 г., 23:34:50 UTC+4 пользователь (неизвестно) написал:
>> On Friday, August 17, 2012 8:37:23 AM UTC-7, Evgeniy Grigoriev wrote:
>>
>>> On 5/4/2012 2:01 AM, Roy Hann wrote:
>>
>>>> Be careful: "some special rules" is handwavy enough that it could mean
>>
>>>> anything--including exposing physical details.
>>
>>> Is such system relational?
>>
>>> I'm asking about this because it seems that I use reference constructions and all these dots seem to be the "physical details" you are speaking about. But in fact it's just play with names which is performed by RENAME operation.
>>
>>
>>
>> When you started this thread I looked at some papers of yours in the arxiv and if that's the technique you're using, you are not being relational. You are just using multiple relation variables as a data structure and you are including values that act as pointers into the data structure by encoding locations in it.
>>
>>
>>
>> To be relational a DBA must associate with every relation variable a predicate about the world that each of its present tuples makes true and each of its absent tuples makes false. It must map a tuple and a world situation to a truth value. With those pointers being there, if you tried to write predicates you would find that you have to mention relation variable names as further parameters. So you would not be giving predicates. You would be giving simultaneous equations whose unknowns were relation variable names, to be solved for valid relation variable values.
>>
>>
>>
>> These equations would happen to form constraints for valid data structure values. But you can't use(update or query) the data structure relationally because you don't have predicates to tell you what the relation variable names in queries mean, and thus what the queries mean. Of course you can use relation operators to manipulate relation variables of your data structure just like you can use any operators to manipulate variables of any types. But that's not querying about the world.
>>
>>
>>
>> Indeed you won't have told the user how to use (update and query) your data structure to describe a world.
>>
>>
>>
>> And you need special operators to manipulate your data structure reasonably. These will be partly describable/implementable in terms of relation operators but also pointer encoding/decoding operators. Yes occasionally a special operator on some arguments can be implemented exactly as a relation operator on the same arguments but this is rare and incidental. When you are using relation operators in expressions that should be special operator calls that is the implementation/representation/"physical" leaking out. (Ironically this lower level is itself relations. Though not relational.)
>>
>>
>>
>> As to your particular messages in this thread, you are not describing what you are doing clearly enough for us to give you an answer. You can't just write something that is consistent with your system. You have to write something that defines it to us.
>>
>>
>>
>> philip
>
> Thank you for answer. Let me start from the end of your message.
>
> 1) About this thread. Here I just want to show that I can use such complex names to name relational attributes.

Define "complex".

> 2) I don't understand your remark about "special" operator. As I understand I can use any copmplex name to denote relation and any copmplex names to denote its attributes. This complexity means nothing for how this relation can be used. From the viewpoint of the formal relational data model, all these complex names are equal to names used to denote abstract relation R(a1, a2…). So usual relational opertion can be used, nothing special.

Since you never spelled out what operators you are defining, whatever
you do is "special." If you are using a relational language, upon which
relational primitives is the language defined?

> 3) About predicates and what I must associate with relation. Relational data model is abstract mathematics. Relation is a formal and meaningless data structure. If a data structure is equal to formal definition of a relation (I prefer to use the one given in "The Theory Of Relational Database" by David Maier) it is a relation. Relation doesn't have to tell something to DBA about the world to be relation. It's not only my viewpoint (http://www.dbdebunk.blogspot.com/2012/07/meaning-and-database-management.html#more)

See Codd's 1972 paper. A relation is a predicate.

> 4) About my papers. I have another ones on ODBMS.ORG where the experimental system is described where this simple rule is implemented fully. But in this thread I want to show that dot in the name is just a part of name. Just a character. Nothing more. (Anyway, thank you very much that you read my paper :) )

Maybe it is, and maybe it isn't. You have not given us enough
information by which to judge.

[com...@hotmail.com]

On Friday, August 17, 2012 4:14:04 PM UTC-7, Evgeniy Grigoriev wrote:

> 1) About this thread. Here I just want to show that I can use such complex names to name relational attributes.

Understand.

> 2) I don't understand your remark about "special" operator. As I understand I can use any copmplex name to denote relation and any copmplex names to denote its attributes. This complexity means nothing for how this relation can be used. From the viewpoint of the formal relational data model, all these complex names are equal to names used to denote abstract relation R(a1, a2…). So usual relational opertion can be used, nothing special.

Read my message. Codd's relation operators are to be used in a certain way. You are building different ("special") operators. You are merely implementing yours in terms of his. You are using them and other non-relation operators to build yours that operate on relations specially. Your operators know about the special structure and disassemble it. (Pointer values or dotted attribute and variable names.) Codd's do not. You aren't even operating on relations: your operator behaviour depends on the names of variables, so your manipulated values are some kind of name+relation things. I told you, you are using relations non-relationally to implement/represent some relation-like and database-like things. As to whether the resulting things and operators are "relational" depends on details you didn't give.

> 3) About predicates and what I must associate with relation. Relational data model is abstract mathematics. Relation is a formal and meaningless data structure. If a data structure is equal to formal definition of a relation (I prefer to use the one given in "The Theory Of Relational Database" by David Maier) it is a relation. Relation doesn't have to tell something to DBA about the world to be relation. It's not only my viewpoint (http://www.dbdebunk.blogspot.com/2012/07/meaning-and-database-management.html#more)

I repeat, just using relations is **not** being relational.

The Maier book begins with "Each row in the table summarizes some object or relationship in the real world." At the dbdebunk link Hugh writes "The meaning of relation SP as understood by the user is: Supplier S# supplies part P# in a quantity of QTY". A formal system does not know meanings, but it produces meanings given other meanings. Codd's relation operators are designed specifically so that if the value of a relation is the set of all tuples that make its predicate true then a query result is the set of tuples that make its predicate true. That query meaning is in terms of the meanings of relations and meanings of the relation operators.

> 4) About my papers. I have another ones on ODBMS.ORG where the experimental system is described where this simple rule is implemented fully. But in this thread I want to show that dot in the name is just a part of name. Just a character. Nothing more. (Anyway, thank you very much that you read my paper :) )

I'll look.

> By the way, from my viewpoint the relation
> (1+2) 'DOC(ID, .No, .Lines.Item , .Items,Qty)
> is full of sence.

Yes, I expect that it is. And I expect that its meaning is in terms of the meaning of DOC.lines and the other dotless-attribute DOC and whatever special operator you are offering that produced it from them.

philip

[Cimode]

It can only be orthogonal to ra. ra theory lack of consistent quantifiers circumvents such possibility.

[Evgeniy Grigoriev]

четверг, 23 августа 2012 г., 3:15:51 UTC+4 пользователь Cimode написал:
what is ra?

[Evgeniy Grigoriev]

Philip, thank you for answer.

>Read my message. Codd's relation operators are to be used in a certain way. You are building different ("special") operators. You are merely implementing yours in terms of his. You are using them and other non-relation operators to build yours that operate on relations specially. Your operators know about the special structure and disassemble it.

Let me try to ask once again. Please, forget about dots from here.

Suppose I have two relation
A( a1, a2, ...)
and
B( b1, b2, ...)
I use some JOIN and RENAME operations to produce new C relation form the two ones
C(c1, c2, ...)

Am I right that I can can use any new names c1, c2 if they are distinct? I don't change the formal predicate itself here. I just change non-logical symbols, just give them other meaning.

Can I use some mnemonic rules to form the names of attributes of C relation from the names of attributes of A and B relations? (E.g. in SQL queries such renaming is used very often - to avoid name duplication, to keep details of data meaning ets.)

But if I can rename attributes manually and if the formation rules of the renaming are defined very strоngly - am I right that I can perform such renaming automatically?

Ok, it's special operator. But because it is composition of traditional relational JOIN and RENAME operations, it's special _relational_ operion. It takes relations as operands and produses a relation. Let us name this special operator as "JOINandRENAMEaccording2SpecialFormationRules".

Does this operator broke the relational system? I think No.

> I repeat, just using relations is **not** being relational.
>
> The Maier book begins with "Each row in the table summarizes some object or relationship in the real world."

Unfortunately I don't have this book in English. But in Russian edition he tryes to forget about any real world meanings on next page. He wants to be formal.

OK, Codd used a term "predicate" in first paper (may be because he wanted to show that this formality can be linked to possible meaning). Mayer didn't use it (as I understand he wanted to be very formal). But they both had got the same mathematics, same mappings between the sames sets of values that forms formal definition of what relation is.

It seems that we think in opposite directions. You assert that (meaningfull?) predicate is main condition that the relation exists. I assert that any formal relation by definition has a predicate - regarless to its meaning "for DBA". Who of us is right? Fact is that if we forget about "meaning" we will mean the same formality.

>At the dbdebunk link Hugh writes "The meaning of relation SP as understood by the user is: Supplier S# supplies part P# in a quantity of QTY". A formal system does not know meanings, but it produces meanings given other meanings.

??? "Formal system produses a meaning" ???
It's something very new to me :) Are you sure?

>Codd's relation operators are designed specifically so that if the value of a relation is the set of all tuples that make its predicate true then a query result is the set of tuples that make its predicate true.

Yes. It's formal rule. Fact is that this trueness doesn't depend on meaning.

> That query meaning is in terms of the meanings of relations...

may be yes, may be no... if non-logicla symbols have some meaming the resulc can have meaning too... but I can replace the non-logicla symbols with new ones - anyway the formal predictae stays the same.

> and meanings of the relation operators.

I don't agree. What is "meaning of opertion" here? they are formal ones.


> I'll look.

You are welcome :). Try this new one http://arxiv.org/abs/1208.3307

Regards,
Evgeniy

[James K. Lowden]

On Fri, 24 Aug 2012 00:40:00 -0700 (PDT)
Evgeniy Grigoriev <grigo...@gmail.com> wrote:

> what is ra?

"ra" here is Relational Algebra.

--jkl

[com...@hotmail.com]

On Friday, August 24, 2012 1:19:27 AM UTC-7, Evgeniy Grigoriev wrote:
> Philip, thank you for answer.

From your messages and papers and quotes and misquotes, you don't understand the relational model. SQL is a mess as a programming language and a mess at being relational. The OMG and O/R camps do not understand the relational model; SQL object extensions are partly not relational, partly messily relational. Your proposals are essentially these. You need to learn about the relational model before you try to unify it with something.

> It seems that we think in opposite directions. You assert that (meaningfull?) predicate is main condition that the relation exists. I assert that any formal relation by definition has a predicate - regarless to its meaning "for DBA". Who of us is right? Fact is that if we forget about "meaning" we will mean the same formality.

The formal system maps relations to relations but also predicates to predicates. You only understand the relation part. You do not understand the predicate part. You do not understand the connection between the parts. So you do not understand the formal system.

> > A formal system does not know meanings, but it produces meanings given other meanings.
> ??? "Formal system produses a meaning" ???

Is a calculus book about expressions like "f(x)" or is it about curves? If you give an expression for a curve then calculus is about getting an expression for another curve: of the slope along the first or of the area under the first. Put a meaning in, get a meaning out. The manipulation in between is per the "form" of expressions instead of their meanings: thus "formal" systems.

> What is "meaning of opertion" here? they are formal ones.

In language semantics we tend to use "meaning" for things mapped to. (It is better not to use that vague term but to name things: values, predicates, extensions, propositions, assertions, operators etc.)

There is a correspondence between relation operators and logic operators (connectives & quantifiers): JOIN with AND, UNION with OR, PROJECT with EXISTS, MINUS with AND NOT, RESTRICT and EXTEND with AND =. This gives the logic "meanings of the relation operators". This also gives the relational "meanings" of the logic operators.

> > That query meaning is in terms of the meanings of relations...

> > and meanings of the relation operators.

One maps between a relation variable name and its predicate and between a relation operator and its logic operator. Thus one maps between a relation expression and a predicate.

> >Codd's relation operators are designed specifically so that if the value of a relation is the set of all tuples that make its predicate true then a query result is the set of tuples that make its predicate true.
> Yes. It's formal rule. Fact is that this trueness doesn't depend on meaning.

You do not understand the important implications of this fundamental rule. It is about how the formal system produces not just relations from relations but predicates from predicates. Everything in the relational model follows from this.

The rule mentions the predicates ("meanings") of relation expressions that are built from given predicates ("meanings") of relation variable names and the above logic operators ("meanings") of relation operators. Thus that every relation expression corresponds to ("means") a predicate expression. And that every predicate expression corresponds to ("means") a relation expression. The rule says that if the value of a relation variable is set to the tuples satisfying its predicate then a relation expression returns the tuples satisfying its predicate. The relation variable predicates are how you set and read a relation variable. An expression's predicate is how you understand a query or update.

If you are not using relations with predicates this way then you are not being relational. If you don't understand this then you don't understand the relational model.

See my message (dense but precise) at:
From: com...@hotmail.com
Newsgroups: comp.databases.theory
Subject: Re: Informal Survey #1 -- joins on foreign keys
Date: Sat, 5 Nov 2011 17:07:26 -0700 (PDT)
https://groups.google.com/d/msg/comp.databases.theory/Hjj_lxB8pXE/aoEDtm__To0J
Maier's book is free online:
http://www.e-booksdirectory.com/listing.php?category=296
Hugh Darwen's bookboon.com free online book is also linked there.

More specific comments later about your operators.

philip

[com...@hotmail.com]

On Friday, August 31, 2012 12:15:34 AM UTC-7, (unknown) wrote:
> See my message (dense but precise) at:
> From: com...@hotmail.com
> Newsgroups: comp.databases.theory
> Subject: Re: Informal Survey #1 -- joins on foreign keys
> Date: Sat, 5 Nov 2011 17:07:26 -0700 (PDT)

Correction:
https://groups.google.com/d/msg/comp.databases.theory/yli9bO8CMb8/AES5in4uqlEJ

philip

[Evgeniy Grigoriev]

Philip, thank you for answer. Unfortunately I am not so sure about my knowledge as you are (that's why I'm asking here).

> From your messages and papers and quotes and misquotes, you don't understand the relational model.

May be.

>SQL is a mess as a programming language and a mess at being relational.

Yes.

>The OMG and O/R camps do not understand the relational model; SQL object extensions are partly not relational, partly messily relational.

Absolutely

>Your proposals are essentially these.

No.

> You need to learn about the relational model before you try to unify it with something.

May be (to learn to learn and to learn :) ) .

> The formal system maps relations to relations but also predicates to predicates. You only understand the relation part. You do not understand the predicate part. You do not understand the connection between the parts. So you do not understand the formal system.

I really think that there is no two different parts. Each relation has predicate by default. When relational operations are performed on the relationas their predicates are operated too. I cannot imagine how it is possibly to operate on relations without operations on their predicates. Also there is no possibility to change a predicate of existing relation.

But I'm just asking about formation rules which allow names of attributes be formed.

It seems that you think that a predicate IS a meaning.

Please, answer me before further discussion - will I change predicate when I change(rename) attribute of some relation?

[Evgeniy Grigoriev]

Correction (to be certain)
...Please, answer me before further discussion - will I change predicate when I rename attribute of some relation?...

[com...@hotmail.com]

On Thursday, September 6, 2012 2:00:59 AM UTC-7, Evgeniy Grigoriev wrote:
> ...Please, answer me before further discussion - will I change predicate when I rename attribute of some relation?...

I have been using "predicate" as a mapping from a world situation and a truth value. (Just as in predicate logic.) RENAME of a relation corresponds to changing all free occurrences in its predicate.

So if the wff R(A,B,...) denotes the predicate for R then the wff for R RENAME A TO N is R(N,B,...). If the wff S(X,Y,...,A,...) denotes the predicate for S then the wff for (R JOIN S) RENAME A TO N is R(N,B,...) AND S(X,Y,...,N,...).

Whatever you do with this value you know that for that state it was the extension of the predicate of that expression.

(A base relation variables has its own predicate. Its value is the extension of its predicate. If you assign an expression's value to a relation variable then that value is assumed to be the extension of the relation variable's predicate in the new state. But that value is still for that earlier state the extension of the predicate of that expression.)

philip

[Evgeniy Grigoriev]

Ok!

> So if the wff R(A,B,...) denotes the predicate for R then the wff for R RENAME A TO N is R(N,B,...). If the wff S(X,Y,...,A,...) denotes the predicate for S then the wff for (R JOIN S) RENAME A TO N is R(N,B,...) AND S(X,Y,...,N,...).

Below is my previous unanswered question (with some comment after //...). Really I cannot understand where is difference here

Suppose I have two relation
A( a1, a2, ...)
and
B( b1, b2, ...)
I use some JOIN and RENAME operations to produce new C relation form the two ones
C(c1, c2, ...)

//So, C is result of operation A RENAME a1 TO c1 ... JOIN B RENAME b1 TO cn...
//what is equal to opearion (A JOIN B) RENAME...


My questions again.

Am I right that I can can use any new names c1, c2 if they are distinct?

Can I use some mnemonic rules (only mnemonic!) to form the names c... of attributes of C relation from the names of attributes of A and B relations? For example name с1 is string "a1.b1"?

Philip, where is difference?

[Roy Hann]

Evgeniy Grigoriev wrote:


> My questions again.
>
> Am I right that I can can use any new names c1, c2 if they are distinct?
>
> Can I use some mnemonic rules (only mnemonic!) to form the names c... of
> attributes of C relation from the names of attributes of A and B

> relations? For example name яПН1 is string "a1.b1"?
>
> Philip, where is difference?

Philip starts with the predicate and you never mention it.

The names in the relation header have to match the names in the
predicate otherwise you are (literally) uttering nonsense.

Change the names in both to anything you like, for any reason you like
(or none at all), but change them in BOTH you must. The only
requirement for a name is that it be comparable (so you know when you're
looking at the same name). Use pictograms, Cyrillic, Zapf-Chancery
dingbats, Latin or Greek alphabets--no one and nothing cares, as long as
the names used in the predicate and the relation header are the the
same.

Of course if you choose names with some mnemonic value it will be easier
to recall the predicate and relation you are working with, but that is a
purely psychological issue. (I doubt anyone on c.d.t. has anything to
say about psychology except that we see some amazing exhibits here
from time to time!)

--
Roy

[Evgeniy Grigoriev]

Thank you Roy. I think almost the same.

But I'm sure that name is not only psychological issue. Just one example (no RM in the one).

I can write X+Y to sum two values. But in modern programm languages I can use very complex names to denote the values. These names are full of meaning, but they are not only psychology, because system translates them into set of operation to obtain the denoted values from memory.

I think that the same process is possible for relations too. Just imagine - a system can analyzes complex names (I write about) and calculate the virtual relation from real relations according to the given complex names and some predefined rules. (Of course the system uses relational operation only in all the calculations.) In this case it's not necessary to define the calculation expression by hand. Only complex names have to be given which correspond to predefined rules. If I use other combination of name I'll get other result. So the rules are equal to definitions of many virtual relation. In this case complex names are full of meaning and also are used by system to obtain denoted relations.

My question again :) Is this system relational?

[Roy Hann]

Evgeniy Grigoriev wrote:

> Thank you Roy. I think almost the same.

> But I'm sure that name is not only psychological issue. Just one
> example (no RM in the one).

> I can write X+Y to sum two values. But in modern programm languages
> I can use very complex names to denote the values. These names are
> full of meaning, but they are not only psychology, because system
> translates them into set of operation to obtain the denoted values
> from memory.

Sounds physical to me.

> I think that the same process is possible for relations too. Just
> imagine - a system can analyzes complex names (I write about) and
> calculate the virtual relation from real relations according to the
> given complex names and some predefined rules. (Of course the system
> uses relational operation only in all the calculations.) In this
> case it's not necessary to define the calculation expression by
> hand. Only complex names have to be given which correspond to
> predefined rules. If I use other combination of name I'll get other
> result. So the rules are equal to definitions of many virtual
> relation. In this case complex names are full of meaning and also
> are used by system to obtain denoted relations.

> My question again :) Is this system relational?

Relational theory explicitly eschews physical concerns. Provided your
physical machinations don't corrupt the logic you are free to do
whatever you want.

But if the physical implementation intrudes even slightly on the logic
(the allowable operations on the symbols in the formal system) then no,
it would not be relational. In fact one struggles to think it could be
anything else but junk.

--
Roy

[com...@hotmail.com]

On Saturday, September 8, 2012 12:07:32 PM UTC-7, Evgeniy Grigoriev wrote:
> My question again :) Is this system relational?

hi Gregoriev,

Here is more cut and paste until I can send my more specific draft. It is an edited message from another forum in reply to someone promoting support for string aggregation and pivot tables. But these are not relational. They are inadequately abstracted representations of formatted output types. You too are essentially using relations to represent a relation-plus-labels type that would likely best merely contain rather than be relations. (The relations are from Date's suppliers & parts database. http://c2.com/cgi/wiki?SupplierPartsDatabase)

philip


I'm all for allowing a language to have parameters and results of all relevant semantic types, like attributes, headings and relations of any heading. But you don't seem to understand enough about working relationally. Also you are failing to abstract, shoehorning things inappropriately into relations.

1. String aggregation.

s# s# list_of_parts char
=================================================
s1 Nut,Bolt,Screw,Cam,Cog
s2 Nut,Bolt
s3 Bolt
s4 Bolt,Screw,Cam

This is a query/relation in name only. It's formatted output. To use this info for further calculation you should use (sp join p){s# pname}:

s# s# pname char
=================================================
s1 Nut
s1 Bolt
s1 Screw
s1 Cam
s1 Cog
s2 Nut
s2 Bolt
s3 Bolt
s4 Bolt
s4 Screw
s4 Cam

If your relation is effectively a value of some graphic-table type, it should accept this as input. Such a type might be implemented using operators mapping from relations to lists and punctuating lists. But it could also do lots of processing relationally, eg extend adding pname concatenated to comma and summarize to concatenate those, or summarize concatenating pnames with commas between.

2. Pivot Tables

s# s# has_p1 has_p2 has_p3 has_p4 has_p5 has_p6
=================================================
s1 Y Y Y Y Y Y
s2 Y Y N N N N
s3 N Y N N N N
s4 N Y N Y Y N

This is also just formatted output. (And again suppliers without parts and parts without suppliers are missing.) The complex predicate for this relation (its label qua graphic-table) is highly structured and requires for understanding undoing much of the mapping that went into generating it: removing "has_" to find out what part is referred to, and converting Y/N to whether a part is possessed. The information a user really wants is:

\p#| p1 p2 p3 p4 p5 p6
\ |
s#\|
---+---------------------------------------
s1 | yes yes yes yes yes yes
s2 | yes yes no no no no
s3 | no yes no no no no
s4 | no yes no yes yes no

Does supplier s# that supplies at least one part supply part p#?

Now we see that we really have two dimensions/axes/attributes (s# and p#) forming a key with further dimension/axis/attribute (the table entries) extending their cross product. The only asymmetry is just which key attribute is displayed horizontally and which vertically. The graphic-table is formatting that is understood by convention to be presenting the info in sp{s# p#}. Ie in (where attribute b fills the graphic-table body):
extend sp{s#} join sp{p#}
add (if tuple{s# s#, p# p#} in sp then 'Y' else 'N') as b
or if you prefer:
extend sp{s# p#} add 'Y' as b
union extend (sp{s#} join sp{p#}) notmatching sp add 'N' as b

s# s# p# p# b ?
=================================================
s1 p1 Y
s1 p2 Y
s1 p3 Y
s1 p4 Y
s1 p5 Y
s2 p1 Y
s2 p2 N
s2 p3 N
...

But beyond that it is not helpful to characterize/abstract this graphic-table as a relation. You need a notion of graphic-table format type/library. Your hundreds of lines should probably be many fewer consisting of simple queries each passed to one of a limited number of formatting functions at the end. It's unlikely you should manipulate such tables rather than further manipulating the underlying displayed data relationally and then formatting that. And the interface for such a graphic-table value should not involve a contorted relation like yours; it should involve the raw info plus ordering attributes and attribute names for ordering and horizontal/vertical placement, etc.

Otherwise what benefit is there to having the info in this format rather than (sp join p){s# p#} or for that matter just sp and p? Moreover by converting (arbitrary numbers of) values into (fixed numbers of) attribute names you have prevented yourself from using basic relation operators to further iterate. Then you think you need to iterate by a separate repetition notation submitting a string to an eval facility!

To implement/call a graphic-table type/library or relations like yours you should be given operators extracting attribute names and headings; equivalently, metadata. But you don't need special pivot operators per se. You could write such operators using ordinary relation operators manipulating relations plus heading/meta data values, tuples and relations, mapping from straightforward simply-predicated manipulation-oriented relations to complexly- and data-dependently- though conventionally- predicated output-oriented graphic-tables or relations.

philip

[Evgeniy Grigoriev]

Hi Philip,

1) My name is Evgeniy (russian Eugene). :)

2) You write a big text, but whem I see through it, I understand that you think that I use domain operations - because all these lists (like "Nut,Bolt,Screw,Cam,Cog") anв boolean values (YES, NO) in fact are results of operaions on domains (they are denoted by you as formatiing functions). I really don't understand what you write about, Philip. Defenitely It's not about my question.

I'm about a play with names of relations and their attributes and about combinations of the names. No domain operations! Ok, imagine two relation

Bill (#No, Date)


Bill.Lines ( #No, #Art, Qty)
// here "Bill.Lines" is just string, just name of relation!

In second relation the name sequense "Bill.Lines.Qty" is defined among other as combination of relation name "Bill.Lines" and attribute name "Qty" . Other name sequence is "Bill.Date": it is defined in first relation.

Imagine that system can analise the name sequences according to some mnemonic rules and automatically calculate new virtual relations just by "correct" name combinations given in them . E.g. system can calculate the next virtual relation just by name sequances (I shoudn't write JOIN and RENAME manually to obtain it)

'Bill (#No, Lines.#Art, Lines.Qty)
// here the "Lines.#Art" and "Lines.Qty" are just attribute names after RENAMing of #Art and Qty.

or

'Bill (#No, Date, Lines.#Art)

They are result of JOIN (by #No) and RENAME operations on source Bill and "Bill.Lines". The system "knows" how the relation should be calculated because of some rules and given "correct" name squences. (E.g. I cannot automatically obtain

'Bill (#No, Date, #Art)

because it's out of rules - sequence "Bill.#Art" is not allowed.)

The main rule is "keep the name sequense".

Roy's answer is clear for me

"Relational theory explicitly eschews physical concerns. Provided your
physical machinations don't corrupt the logic you are free to do
whatever you want."

but I'm still not sure if my mashinations is not physical.

[com...@hotmail.com]

On Monday, September 10, 2012 8:56:06 PM UTC-7, Evgeniy Grigoriev wrote:
> 1) My name is Evgeniy (russian Eugene). :)

Sorry, I do know that Evgeniy. Frequently play hockey with an Evgeniy, Russian accent included.

> 2) You write a big text,

Cutting and pasting was a fast way to explain more.

> but whem I see through it, I understand that you think that I use domain operations

I know what you are doing. I am just showing you two other proposals that encode information in relations inappropriately/non-relationally. In that sense they are similar to yours. (Observe that both also involve encoding into headings. Although that is coincidental.) Try to understand what they are doing, what I say their problems are and what I say should be done instead. I will send a message about yours in particular. If you want to learn stop focusing on why you are right and start focusing on how you might be wrong.

On Thursday, September 6, 2012 1:53:18 AM UTC-7, Evgeniy Grigoriev wrote:
> >The OMG and O/R camps do not understand the relational model; SQL object extensions are partly not relational, partly messily relational.

> >Your proposals are essentially these.
> No.

See the Third-Generation Database System Manifesto for your O/R mapping and dotted name sequences in SQL style queries. Yes your using those sequences as attributes is unique.

> I really don't understand what you write about, Philip. Definitely It's not about my question.

The point is that your use of relations is non-relational in a similar way. Seek the similarities.

> Roy's answer is clear for me
> "Relational theory explicitly eschews physical concerns. Provided your physical machinations don't corrupt the logic you are free to do whatever you want."
> but I'm still not sure if my mashinations is not physical.

(An inadvertent pun. You mean "machinations". Look up "mash". I like it.)

When he writes about the "physical" he means "implementation" or "representation".

On Monday, September 10, 2012 12:53:36 PM UTC-7, (unknown) wrote:
> But these are not relational. They are inadequately abstracted representations of formatted output types. You too are essentially using relations to represent a relation-plus-labels type that would likely best merely contain rather than be relations.

philip

[Evgeniy Grigoriev]

Thank you Philip.

Once again to be clear.

"So if the wff R(A,B,...) denotes the predicate for R then the wff for R RENAME A TO N is R(N,B,...). If the wff S(X,Y,...,A,...) denotes the predicate for S then the wff for (R JOIN S) RENAME A TO N is R(N,B,...) AND S(X,Y,...,N,...). "

If a system calculates (X,Y,...,N,...) automatically (according to some predefined mnemonic rules) as (R JOIN S) RENAME A TO N is R(N,B,...), the system is not relational.

(Yes/No)?

But if a system allow the S relational to be calculated as the same as (R JOIN S) RENAME A TO N is R(N,B,...) by hand - the system is relational.

(Yes/No)?

[Evgeniy Grigoriev]

CORRECTION(Dont reaв previous message)

I've formulated my question in wrong way.

"So if the wff R(A,B,...) denotes the predicate for R then the wff for R RENAME A TO N is R(N,B,...). If the wff S(X,Y,...,A,...) denotes the predicate for S then the wff for (R JOIN S) RENAME A TO N is R(N,B,...) AND S(X,Y,...,N,...). "

To be correst, let me first ask you about virtual view which is (I hope) possible for you. Can I define some virtual view Q as result of (R JOIN S)? Ok, "the wff for for (R JOIN S) RENAME A TO N is R(N,B,...) AND S(X,Y,...,N,...)" but was is name "Q" here?

[com...@hotmail.com]

On Tuesday, September 11, 2012 3:51:37 AM UTC-7, Evgeniy Grigoriev wrote:

> "So if the wff R(A,B,...) denotes the predicate for R then the wff for R RENAME A TO N is R(N,B,...). If the wff S(X,Y,...,A,...) denotes the predicate for S then the wff for (R JOIN S) RENAME A TO N is R(N,B,...) AND S(X,Y,...,N,...). "

> To be correst, let me first ask you about virtual view which is (I hope) possible for you. Can I define some virtual view Q as result of (R JOIN S)? Ok, "the wff for for (R JOIN S) RENAME A TO N is R(N,B,...) AND S(X,Y,...,N,...)" but was is name "Q" here?

Do you mean, what is a wff for the predicate of Q?

Q has an associated relational expression R JOIN S. So a wff for Q's associated predicate is R(A,B,...) AND S(X,Y,...,A,...). This is because predicate-of-(R JOIN S) is predicate-of-R AND predicate-of-S. (We were given wffs for these two predicates.)

philip

[Evgeniy Grigoriev]

No I mean how the name Q links to the wff? Where a info exists that wff for Q is R(A,B,...) AND S(X,Y,...,A,...)? I think the wff is given by the fact that Q is R JOIN S (once again - I cannot imagine how it is possibly to operate on relations without operations on their predicates). But instead of "Q" i can use any string in any language or any value of any sign or anything else. There is no link between NAME of a virtual relation and WFF of the relation.

My questin is about how posiible names of virtual relation can be used. So my question is - why do you tell me about predicates?