I noticed a recurring commercial argumentation about creating *behavior* into components (named classes). This caracteristics is often presented as being a differentiation of relational model where no
such thing really exists (and in fact is not necessary). In a word, In
OO approach (for whatever it may rely on), one of the main limitation of relational model would be not to allow its elementary components to emulate elementary predefined processes (transformations for instance).
I have the impression, there is a concept, unbearable to some programmers that data management systems can not be anything else than a mechanized set of tool that could help structuring data for human interpretation. On that standpoint, relational model components reflect an approximation of *meaning* concept as being a contextualized
and specific combination of constraints, business rules to make predefined inferences about that data for preparing interpretation. Processes are defined only according to specifically defined inferences. On the other side, OO approach seems to advocate that some
level of elementary process autonomy will end up creating *some* form of intelligence thanks to some cumulative effect. On such perspective, I start suspecting all debate stating behavior lacking in the relational model is an empty unfounded attempt of some IT professional to project their scifi fantasies about what system could do and what they can actually do in a realistic manner.
On the other side, some OO advocates state that OO approach brings some
features that would seem to better implementations of subtype and supertypes features through inheritance as well as a better in memory physical handling of non primitive types than what we are accustomed to
with traditional SQL implementations.
I am curious about your opinion about this matter as this is a new board for me. (Sorry if you have noticed some english errors as it is not my native language) so bear with me please.
Cimode wrote: > I noticed a recurring commercial argumentation about creating > *behavior* into components (named classes). This caracteristics is > often presented as being a differentiation of relational model where no
> such thing really exists (and in fact is not necessary). In a word, In
> OO approach (for whatever it may rely on), one of the main limitation > of relational model would be not to allow its elementary components to > emulate elementary predefined processes (transformations for instance).
You don't have to worry all that much about what the relational model allows or doesn't allow. As anybody here can tell you, there are no pure relational databases in the Real World.
What we have is quasi-relational table-based systems that in fact can handle processes very well.
The problem is in how you think about the process, especially transformations. All transformations and processes can be mapped into simple precise definitions of what values should be written to what columns of what tables. In other words, processes resolve to database specifications. If you can specify it, you can code it.
When trying to specify processes in terms of tables, the relational concepts of unique key and foreign key come in very handy for specifying how data should be moved from place to place as it is transformed. Adding basic formulas finishes it off.
So sure, the RM can't do it, but who cares? Table-centric systems can.
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth@(Sec)ure(Dat)a(.com)
<<You don't have to worry all that much about what the relational model allows or doesn't allow. As anybody here can tell you, there are no pure relational databases in the Real World. >>I am puzzled by this statement...Everything in my experience teaches me that the current SQL implementation have recurring problems because they actuall y do not support correctly relational concepts...
<<What we have is quasi-relational table-based systems that in fact can handle processes very well. >>What do you exactly mean by handling processes very well? Most systems I face dayly, present grave performance and administration problems that could be avoided if rules dictated by normalization were respected...
<<Table-centric systems can. >>I see...What exactly are table centric systems...Do you mean SQL based systems (ORACLE, DB2, SQL Server)
My concern is about how OO mechanisms could be utilized to allow better physical implementation of relational concepts...Is Java a potentially language than SQL for data manipulation, data definition (or both)...Thanks for your input...
> <<You don't have to worry all that much about what the relational model > allows > or doesn't allow. As anybody here can tell you, there are no pure > relational databases in the Real World. >> > I am puzzled by this > statement...Everything in my experience teaches me that the current SQL > implementation have recurring problems because they actuall y do not > support correctly relational concepts...
Like what problems? Can you give a few examples?
> <<What we have is quasi-relational table-based systems that in fact can > handle > processes very well. >> > What do you exactly mean by handling processes > very well? Most systems I face dayly, present grave performance and > administration problems that could be avoided if rules dictated by > normalization were respected...
You clipped it all out. I said that being able to specify transformations and automations would do the trick. That's how we do it here at SDS.
There are some exceptions that require hoop-jumping, but they are thankfully very rare.
> <<Table-centric systems can. >>I see...What exactly are table centric > systems...Do you mean SQL based systems (ORACLE, DB2, SQL Server)
> My concern is about how OO mechanisms could be utilized to allow better > physical implementation of relational concepts...Is Java a potentially > language than SQL for data manipulation, data definition (or > both)...Thanks for your input...
I went the other way myself, putting more abilities into the server and using less OO, and it has served our company and our customers well.
Cheers,
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth@(Sec)ure(Dat)a(.com)
<<Like what problems? Can you give a few examples?>> Sure. I was refering to problems such as data integrity and data redundancy which create lots of performance bottlenecks...For instance, people allow NULL values into tables which create the need to add additional excluding conditions (IS NULL, IS NOT NULL...) into select procedures to get correct results in COUNT statements. As a consequence, they degrade performance (both response time and througput) when they do that...If NULL were not allowed in the first place, then these additional conditions would not be used...
<<I said that being able to specify transformations
> and automations would do the trick.
There are some exceptions that require hoop-jumping, but they are thankfully very rare.
>> Could you give few examples to illustrate what you mean by transformations and automations? and the exceptions you are refering to?
<<I went the other way myself, putting more abilities into the server and
> using less OO, and it has served our company and our customers well>>
I don't believe we are speaking about the same thing.. It seems you are refering to centralizing processes into server side which is probably more practical in all senses...I was however refering to using OO mechanisms and features as a replacement to SQL (as a server side language) for data manipulation and definition...
One of the main current flaws of current SQL DBMS systems is their incapability to implement the multidimensionality of relvars. The main reason seems to be the lack of independence between the physical layer and logical layer the represent the data. In several DBMS tuples are right away on disk projections imposing that all tables are considered bidimensional. In fact, it should not be the case because a bidimensional RTable is only a *representation* of some entity. An interesting analogy that may help communication, is Rubi's Cube (3 dimensional): looking at one face of the cube it's only one possible representation of the cube (being the relvar)...Thank you for bringing some insight (flamers please refrain) onto how OO mechanism may help separate the logical operation (in memory) from physical layer... Subject is launched...
Cimode wrote: > <<Like what problems? Can you give a few examples?>> > Sure. I was refering to problems such as data integrity and data > redundancy which create lots of performance bottlenecks...For instance, > people allow NULL values into tables which create the need to add > additional excluding conditions (IS NULL, IS NOT NULL...) into select > procedures to get correct results in COUNT statements. As a > consequence, they degrade performance (both response time and > througput) when they do that...If NULL were not allowed in the first > place, then these additional conditions would not be used...
> <<I said that being able to specify transformations > > and automations would do the trick. > There are some exceptions that require hoop-jumping, but they are > thankfully > very rare. > >> Could you give few examples to illustrate what you mean by transformations and automations? and the exceptions you are refering to?
> <<I went the other way myself, putting more abilities into the server > and > > using less OO, and it has served our company and our customers well>> > I don't believe we are speaking about the same thing.. > It seems you are refering to centralizing processes into server side > which is probably more practical in all senses...I was however refering > to using OO mechanisms and features as a replacement to SQL (as a > server side language) for data manipulation and definition...
> One of the main current flaws of current SQL DBMS systems is their > incapability to implement the multidimensionality of relvars.
This does not make any sense, the dimension of a relvar is the number of attributes.
> The main > reason seems to be the lack of independence between the physical layer > and logical layer the represent the data. In several DBMS tuples are > right away on disk projections imposing that all tables are considered > bidimensional.
The only way to do this is to force all logical tables to have two attributes.
> In fact, it should not be the case because a > bidimensional RTable is only a *representation* of some entity. An > interesting analogy that may help communication, is Rubi's Cube (3 > dimensional): looking at one face of the cube it's only one possible > representation of the cube (being the relvar)
I suppose that you know how to represent a cube with a table.
> some insight (flamers please refrain) onto how OO mechanism may help > separate the logical operation (in memory) from physical layer...
Are you suggesting that the memory is less physical than the disk?
Thank you for your feedback. I do not believe I am making any confusion but I should rephrase otherwise for the sake of clarity. (Again English is not my native language so expressing consensual terminology in english is difficult to me. As Fabian PASCAL declared "commitment" to precise terminology is crucial into abording relational model matters).
First, I make a clear distinction between SQL and its current proprietary implementations(DB2, ORACLE, SQL Server...). As you know, several features specified in standard (SQL92) have not been implemented, creating lots of overhead work at applicative level into guaranteing integrity at physical implementation time (ex:create table) which makes SQL implementations and therefore SQL DBMS's unefficient. Of course, there is no better alternative as SQL based systems are still the best we have.
Second, I make a clear distinction between SQL tables *as implemented currently* and relvars (called also R-tables). On that standpoint, I do not see how are current *physical* implementations of SQL are multidimensional when all the ones I know (but I only know the main exposed above) use direct image storage of tuple physical implementation.(totally defeating relational independence between logical and physical layer). So I am curious to why, presicely you are saying that a SQL table is multidimensional. My guess is that you are refering to what SQL should be as opposed as to how it is implemented. On that case, I agree with that statement. On the opposite case
Third, the hidden agenda of this thread is to focus discussion on in-memory logic projection of relvars assuming total independence between disk based storage and representation of R-Tables at runtime. As you also know current SQL implementations (and SQL implemented tables) are direct projection of physically static (generally bidimensional) representation of tuples. On such perspective, the little education I have about OO mechanisms encourages me to seek discussion with OO audience to educate myself about possibilities OO can offer to drive a better relational implementation.
So no. I do not believe what I am writing is nonsense. So I will stick to what I have declared previously. Do not hesitate to contradict me if you believe I missed some points. Thank you for your implication in this thread.
Bob Badour wrote: > Cimode wrote: > > One of the main current flaws of current SQL DBMS systems is their > > incapability to implement the multidimensionality of relvars.
> With all due respect, what you wrote is nonsense. An SQL table of degree > N (ie. with N columns) has N dimensions.
Cimode wrote: > Thank you for your feedback. I do not believe I am making any > confusion but I should rephrase otherwise for the sake of clarity. > (Again English is not my native language so expressing consensual > terminology in english is difficult to me. As Fabian PASCAL declared > "commitment" to precise terminology is crucial into abording relational > model matters).
> First, I make a clear distinction between SQL and its current > proprietary implementations(DB2, ORACLE, SQL Server...). As you know, > several features specified in standard (SQL92) have not been > implemented, creating lots of overhead work at applicative level into > guaranteing integrity at physical implementation time (ex:create table) > which makes SQL implementations and therefore SQL DBMS's unefficient. > Of course, there is no better alternative as SQL based systems are > still the best we have.
I am not certain I agree with that last sentence. Of the dbmses that have widely or deeply penetrated the market, SQL based systems are the best we have. There may or may not be better alternatives that are relatively unknown.
> Second, I make a clear distinction between SQL tables *as implemented > currently* and relvars (called also R-tables). On that standpoint, I > do not see how are current *physical* implementations of SQL are > multidimensional when all the ones I know (but I only know the main > exposed above) use direct image storage of tuple physical > implementation.(totally defeating relational independence between > logical and physical layer).
That's a different issue. I agree they provide insufficient physical independence. However, that does not change the degree of a table and does not change the fact that the degree is a direct measure of the dimensions.
So I am curious to why, presicely you are
> saying that a SQL table is multidimensional. My guess is that you are > refering to what SQL should be as opposed as to how it is implemented.
No, I am referring to both. Consider the following SQL table:
Create table s5 ( x as integer not null , y as integer not null , z as integer not null ) primary key (x,y,z);
insert into s5 values(0,0,5); insert into s5 values(0,0,-5); insert into s5 values(0,5,0); insert into s5 values(0,-5,0); insert into s5 values(5,0,0); insert into s5 values(-5,0,0); insert into s5 values(0,3,4); insert into s5 values(0,3,-4); insert into s5 values(0,-3,4); insert into s5 values(0,-3,-4); insert into s5 values(0,4,3); insert into s5 values(0,4,-3); insert into s5 values(0,-4,3); insert into s5 values(0,-4,-3); insert into s5 values(3,0,4); insert into s5 values(3,0,-4); insert into s5 values(-3,0,4); insert into s5 values(-3,0,-4); insert into s5 values(4,0,3); insert into s5 values(4,0,-3); insert into s5 values(-4,0,3); insert into s5 values(-4,0,-3); insert into s5 values(3,4,0); insert into s5 values(3,-4,0); insert into s5 values(-3,4,0); insert into s5 values(-3,-4,0); insert into s5 values(4,3,0); insert into s5 values(4,-3,0); insert into s5 values(-4,3,0); insert into s5 values(-4,-3,0);
Regardless of implementation, a sphere of radius 5 has three dimensions as does the set of integral points on a sphere of radius 5. The table s5 above has degree three and three dimensions: x, y and z.
> On that case, I agree with that statement. On the opposite case
Agreeing with something I never said seems pointless.
> Third, the hidden agenda of this thread is to focus discussion on > in-memory logic projection of relvars assuming total independence > between disk based storage and representation of R-Tables at runtime. > As you also know current SQL implementations (and SQL implemented > tables) are direct projection of physically static (generally > bidimensional) representation of tuples.
As a matter of fact, I do not know that because it is in fact not true.
On such perspective, the
> little education I have about OO mechanisms encourages me to seek > discussion with OO audience to educate myself about possibilities OO > can offer to drive a better relational implementation.
I think you will find far more fertile ground elsewhere.
> So no. I do not believe what I am writing is nonsense. So I will > stick to what I have declared previously. Do not hesitate to > contradict me if you believe I missed some points. Thank you for your > implication in this thread.
When you write that an SQL table of degree 3 has two dimensions, then what you write is nonsense regardless of your belief.
<< This does not make any sense, the dimension of a relvar is the number of attributes.>>Absolutely. but SQL table implementations are not relvar, just a possible representation of a relvar. Commonly implemented SQL DBMS Tables are bidimensional.
<< The only way to do this is to force all logical tables to have two attributes.>>Why is that? What sources makes you believe that? (Curious about that assertion) Are you refering to Transrelational Model?
<<I suppose that you know how to represent a cube with a table.>> It is an analogy used for communication's sake. You misread and misunderstood my comment. I said that a face of a cube is bidimensional and is a comparable to what a SQL Table is to a relvar. (the relvar being a 3 dimensional relvar). This analogy has been used by DATE and PASCAL and I find it very valid.
<<Are you suggesting that the memory is less physical than the disk?>>Interesting question but the answer is obviously no. The argument here is about getting better independence *progressively* through thinking as to how in-memory representation of relvar could be more truthful to what a relvar . The question is whether OO in-memory mechanisms could support such effort. And how?
> > One of the main current flaws of current SQL DBMS systems is their > > incapability to implement the multidimensionality of relvars.
> This does not make any sense, the dimension of a relvar is the number > of attributes.
> > The main > > reason seems to be the lack of independence between the physical layer > > and logical layer the represent the data. In several DBMS tuples are > > right away on disk projections imposing that all tables are considered > > bidimensional.
> The only way to do this is to force all logical tables to have two > attributes.
> > In fact, it should not be the case because a > > bidimensional RTable is only a *representation* of some entity. An > > interesting analogy that may help communication, is Rubi's Cube (3 > > dimensional): looking at one face of the cube it's only one possible > > representation of the cube (being the relvar)
> I suppose that you know how to represent a cube with a table.
> > some insight (flamers please refrain) onto how OO mechanism may help > > separate the logical operation (in memory) from physical layer...
> Are you suggesting that the memory is less physical than the disk?
> << This does not make any sense, the dimension of a relvar is the > number > of attributes.>>Absolutely. but SQL table implementations are not > relvar, just a possible representation of a relvar. Commonly > implemented SQL DBMS Tables are bidimensional.
VAR CUBE RELATION { X REAL, Y REAL, Z REAL}
TABLE CUBE(X REAL, Y REAL, Z REAL)
What's the substantial difference with repect to 'dimensionality' ?
> <<I suppose that you know how to represent a cube with a table.>> It is > an analogy used for communication's sake. You misread and > misunderstood my comment. I said that a face of a cube is > bidimensional and is a comparable to what a SQL Table is to a relvar. > (the relvar being a 3 dimensional relvar). This analogy has been used > by DATE and PASCAL and I find it very valid.
<<I am not certain I agree with that last sentence.>>Can you ellaborate on that? What do you have in mind?
<<That's a different issue.>>You really think so? I would argue that it is too closely related to to be ignored.
<<However, that does not change the degree of a table and does not change the fact that the degree is a direct measure of the dimensions.>> Yes. So. I have never denied that. This is why I made a distinction between SQL tables as they are implemented and SQL tables as they should be represented. Do you have any idea onto how an in memory SQL table footprint looks like on current SQL DBMS?
<<No, I am referring to both. Consider the following SQL table:>> I do have the impression we are talking of different things. I do not disagree with anything you have declared but you totally miss the point I tried explaining several times .
If you consider that SQL tables in traditional DBMS are multidimensional because syntaxically seem to be you are placing yourself exclusively at high level not on in memory level. In which case I understand better the source of confusion.(which is my mistake, I should have been more cautious about that).
<<Regardless of implementation, a sphere of radius 5 has three dimensions as does the set of integral points on a sphere of radius 5. The table s5 above has degree three and three dimensions: x, y and z.>> Yes. That's not the point.
<<As a matter of fact, I do not know that because it is in fact not true.>> I don't understand this statement. How can you not know something and disqualify it as not being true. Could you ellaborate?
<<I think you will find far more fertile ground elsewhere.>>Probably. Looking at the spirit of most comments I have read in other threads NG, it seems collaboration is not the main overall drive in this NG. Thank you for pointing it out.
<< When you write that an SQL table of degree 3 has two dimensions, then what you write is nonsense regardless of your belief.>>
I have not written that anywhere (have not used degree). I am curious however as to *what* exactly makes you believe that I said that.
If you don't mind, I will use your example to clarify:
...Consider the following relvar
T5: x,y,z
...then consider its SQL counterpart...
create table s5 ( x as integer not null , y as integer not null , z as integer not null ) primary key (x,y,z)
...then consider the following view
select x, y, z from s5
...my point is that the following possible output in one possible representation of the relvar...
1, 2, 3 3, 5, 5
..considering this output is a direct disk image implementation meaning disk storage mechanism and in-memory representation in current SQL DBMS are *physically* storing
Adress 1/ 1, 2, 3 Adress 2/ 3, 5, 5
I do not understand why you advocate the idea that this particular physical implementation is anything else than bidimensional? (The relvar is not of course). I think I missed something.
Thank you for your valuable insight. Exchanging online is a difficult exercice.
> > Thank you for your feedback. I do not believe I am making any > > confusion but I should rephrase otherwise for the sake of clarity. > > (Again English is not my native language so expressing consensual > > terminology in english is difficult to me. As Fabian PASCAL declared > > "commitment" to precise terminology is crucial into abording relational > > model matters).
> > First, I make a clear distinction between SQL and its current > > proprietary implementations(DB2, ORACLE, SQL Server...). As you know, > > several features specified in standard (SQL92) have not been > > implemented, creating lots of overhead work at applicative level into > > guaranteing integrity at physical implementation time (ex:create table) > > which makes SQL implementations and therefore SQL DBMS's unefficient. > > Of course, there is no better alternative as SQL based systems are > > still the best we have.
> I am not certain I agree with that last sentence. Of the dbmses that > have widely or deeply penetrated the market, SQL based systems are the > best we have. There may or may not be better alternatives that are > relatively unknown.
> > Second, I make a clear distinction between SQL tables *as implemented > > currently* and relvars (called also R-tables). On that standpoint, I > > do not see how are current *physical* implementations of SQL are > > multidimensional when all the ones I know (but I only know the main > > exposed above) use direct image storage of tuple physical > > implementation.(totally defeating relational independence between > > logical and physical layer).
> That's a different issue. I agree they provide insufficient physical > independence. However, that does not change the degree of a table and > does not change the fact that the degree is a direct measure of the > dimensions.
> So I am curious to why, presicely you are > > saying that a SQL table is multidimensional. My guess is that you are > > refering to what SQL should be as opposed as to how it is implemented.
> No, I am referring to both. Consider the following SQL table:
> Create table s5 ( > x as integer not null > , y as integer not null > , z as integer not null > ) primary key (x,y,z);
> insert into s5 values(0,0,5); > insert into s5 values(0,0,-5); > insert into s5 values(0,5,0); > insert into s5 values(0,-5,0); > insert into s5 values(5,0,0); > insert into s5 values(-5,0,0); > insert into s5 values(0,3,4); > insert into s5 values(0,3,-4); > insert into s5 values(0,-3,4); > insert into s5 values(0,-3,-4); > insert into s5 values(0,4,3); > insert into s5 values(0,4,-3); > insert into s5 values(0,-4,3); > insert into s5 values(0,-4,-3); > insert into s5 values(3,0,4); > insert into s5 values(3,0,-4); > insert into s5 values(-3,0,4); > insert into s5 values(-3,0,-4); > insert into s5 values(4,0,3); > insert into s5 values(4,0,-3); > insert into s5 values(-4,0,3); > insert into s5 values(-4,0,-3); > insert into s5 values(3,4,0); > insert into s5 values(3,-4,0); > insert into s5 values(-3,4,0); > insert into s5 values(-3,-4,0); > insert into s5 values(4,3,0); > insert into s5 values(4,-3,0); > insert into s5 values(-4,3,0); > insert into s5 values(-4,-3,0);
> Regardless of implementation, a sphere of radius 5 has three dimensions > as does the set of integral points on a sphere of radius 5. The table s5 > above has degree three and three dimensions: x, y and z.
> > On that case, I agree with that statement. On the opposite case
> Agreeing with something I never said seems pointless.
> > Third, the hidden agenda of this thread is to focus discussion on > > in-memory logic projection of relvars assuming total independence > > between disk based storage and representation of R-Tables at runtime. > > As you also know current SQL implementations (and SQL implemented > > tables) are direct projection of physically static (generally > > bidimensional) representation of tuples.
> As a matter of fact, I do not know that because it is in fact not true.
> On such perspective, the > > little education I have about OO mechanisms encourages me to seek > > discussion with OO audience to educate myself about possibilities OO > > can offer to drive a better relational implementation.
> I think you will find far more fertile ground elsewhere.
> > So no. I do not believe what I am writing is nonsense. So I will > > stick to what I have declared previously. Do not hesitate to > > contradict me if you believe I missed some points. Thank you for your > > implication in this thread.
> When you write that an SQL table of degree 3 has two dimensions, then > what you write is nonsense regardless of your belief.
> > Bob Badour wrote:
> >>Cimode wrote:
> >>>One of the main current flaws of current SQL DBMS systems is their > >>>incapability to implement the multidimensionality of relvars.
> >>With all due respect, what you wrote is nonsense. An SQL table of degree > >>N (ie. with N columns) has N dimensions.
<<What's the substantial difference with repect to 'dimensionality' ?>> Mainly that SQL current implementation are direct image implementation which limits their ability to represent relvar adequately. They can only manipulate relvar on a representation per representation basis.
<<See above, and what analogy do you have in mind ?>>Please read above. A ruby's cube has 3 dimensions (width, length, depth). When you look at one face of the cube you see only 2 dimensions. These 2 dimensions are on possible representation of the cube.
vc wrote: > Cimode wrote: > > Thank you for your feedback.
> > << This does not make any sense, the dimension of a relvar is the > > number > > of attributes.>>Absolutely. but SQL table implementations are not > > relvar, just a possible representation of a relvar. Commonly > > implemented SQL DBMS Tables are bidimensional.
> VAR CUBE RELATION { X REAL, Y REAL, Z REAL}
> TABLE CUBE(X REAL, Y REAL, Z REAL)
> What's the substantial difference with repect to 'dimensionality' ?
> > <<I suppose that you know how to represent a cube with a table.>> It is > > an analogy used for communication's sake. You misread and > > misunderstood my comment. I said that a face of a cube is > > bidimensional and is a comparable to what a SQL Table is to a relvar. > > (the relvar being a 3 dimensional relvar). This analogy has been used > > by DATE and PASCAL and I find it very valid.
> See above, and what analogy do you have in mind ?
> Second, I make a clear distinction between SQL tables *as implemented > currently* and relvars (called also R-tables). On that standpoint, I > do not see how are current *physical* implementations of SQL are > multidimensional when all the ones I know (but I only know the main > exposed above) use direct image storage of tuple physical > implementation.(totally defeating relational independence between > logical and physical layer).
Okay; you're discussing the physical layer here. (Although your parenthetical remark is incorrect; the choice of a particular implementation strategy isn't what determines whether you have independence or not.)
> So I am curious to why, presicely you are > saying that a SQL table is multidimensional.
Whoops! Now you're talking about the logical layer.
As Bob already said, a relation with N attributes is n-dimensional. This is true regardless of whether you implement that relation with a row store or a column store or a piggy bank of slips of paper. This is by definition.
> My guess is that you are > refering to what SQL should be as opposed as to how it is implemented. > On that case, I agree with that statement. On the opposite case
Not really; the reference is to the logical layer rather than the physical layer. There's no "should be" here; that's how it is.
> Third, the hidden agenda of this thread is to focus discussion on > in-memory logic projection of relvars assuming total independence > between disk based storage and representation of R-Tables at runtime. > As you also know current SQL implementations (and SQL implemented > tables) are direct projection of physically static (generally > bidimensional) representation of tuples.
No, I don't think that's correct at all. Physical memory is unidimensional; everything else is a layer on top of that.
> On such perspective, the > little education I have about OO mechanisms encourages me to seek > discussion with OO audience to educate myself about possibilities OO > can offer to drive a better relational implementation.
Well, I wouldn't do that if I were you. I think your best bet is to study the existing literature on relational implementation. Read ten papers and see if you think OO has something useful to say.
<<Okay; you're discussing the physical layer here. (Although your parenthetical remark is incorrect; the choice of a particular implementation strategy isn't what determines whether you have independence or not.)>>
You consider relvar and R-Table physical layer? Can't agree with that (must have missed something). Only SQL implementation (storage, operation) are physical layer. Also, while you can logically *conclude* that you do or do not have data independence for a particular physical implementation puts emphasis on implementation layer to satisfy requirements for data independence.
<< No, I don't think that's correct at all. Physical memory is unidimensional;>> Please explain your point.
<< Well, I wouldn't do that if I were you. I think your best bet is to study the existing literature on relational implementation. Read ten papers and see if you think OO has something useful to say.>> Thanks for the word of caution.(I appreciate) but I already started doing that. Diversifying sources helps too. ;)
> > Second, I make a clear distinction between SQL tables *as implemented > > currently* and relvars (called also R-tables). On that standpoint, I > > do not see how are current *physical* implementations of SQL are > > multidimensional when all the ones I know (but I only know the main > > exposed above) use direct image storage of tuple physical > > implementation.(totally defeating relational independence between > > logical and physical layer).
> Okay; you're discussing the physical layer here. (Although your > parenthetical remark is incorrect; the choice of a particular > implementation strategy isn't what determines whether > you have independence or not.)
> > So I am curious to why, presicely you are > > saying that a SQL table is multidimensional.
> Whoops! Now you're talking about the logical layer.
> As Bob already said, a relation with N attributes is n-dimensional. > This is true regardless of whether you implement that relation > with a row store or a column store or a piggy bank of slips > of paper. This is by definition.
> > My guess is that you are > > refering to what SQL should be as opposed as to how it is implemented. > > On that case, I agree with that statement. On the opposite case
> Not really; the reference is to the logical layer rather than the > physical layer. There's no "should be" here; that's how it is.
> > Third, the hidden agenda of this thread is to focus discussion on > > in-memory logic projection of relvars assuming total independence > > between disk based storage and representation of R-Tables at runtime. > > As you also know current SQL implementations (and SQL implemented > > tables) are direct projection of physically static (generally > > bidimensional) representation of tuples.
> No, I don't think that's correct at all. Physical memory is > unidimensional; > everything else is a layer on top of that.
> > On such perspective, the > > little education I have about OO mechanisms encourages me to seek > > discussion with OO audience to educate myself about possibilities OO > > can offer to drive a better relational implementation.
> Well, I wouldn't do that if I were you. I think your best bet is to > study the existing literature on relational implementation. > Read ten papers and see if you think OO has something > useful to say.
Cimode wrote: > <<Okay; you're discussing the physical layer here. (Although your > parenthetical remark is incorrect; the choice of a particular > implementation strategy isn't what determines whether > you have independence or not.)>>
> You consider relvar and R-Table physical layer? Can't agree with that > (must have missed something).
When you snip as much as you do, it is harder for me to have a dialog. You talked about physical concerns, which I pointed out, and now you say you weren't discussing physical concerns, but you've snipped the paragraph I was responding to, which discussed implementation and physical concerns.
I'll try to be very clear:
In the RM, and in SQL, the logical model is what it is: multidimensional. This is true regardless of the physical implementation.
It might be easier if you picked one level, physical or logical, and stuck to discussing that. When you switch back and forth so quickly, our communication seems to break down.
> << No, I don't think that's correct at all. Physical memory is > unidimensional;>> > Please explain your point.
You keep saying that physical representation is two dimensional. But that's not correct. Physical memory is one dimensional; it is a single line of memory from address 0 to address n.
If by "bidimensional" you mean that SQL is always implemented as a simple row store, this is not correct. There are products that are column stores. There are other hybrid approaches. It is not so simple.
> << Well, I wouldn't do that if I were you. I think your best bet is to > study the existing literature on relational implementation. > Read ten papers and see if you think OO has something > useful to say.>> Thanks for the word of caution.(I appreciate) but I > already started doing that. Diversifying sources helps too. ;)
Cimode wrote: > <<I am not certain I agree with that last sentence.>>Can you ellaborate > on that? What > do you have in mind?
I already elaborated. You simply omitted it from your excerpt.
> <<That's a different issue.>>You really think so? I would argue that > it is too closely related to to be ignored.
Since you removed all context of what I wrote, I no longer have any idea what we are discussing.
> <<However, that does not change the degree of a table and > does not change the fact that the degree is a direct measure of the > dimensions.>> Yes. So. I have never denied that. This is why I > made a distinction between SQL tables as they are implemented and SQL > tables as they should be represented.
Which is irrelevant, as I already explained.
> <<Regardless of implementation, a sphere of radius 5 has three > dimensions > as does the set of integral points on a sphere of radius 5. The table > s5 > above has degree three and three dimensions: x, y and z.>> > Yes. That's not the point.
If you are trying to make a different point, I suggest you use words that mean something else, then.
> <<As a matter of fact, I do not know that because it is in fact not > true.>> > I don't understand this statement. How can you not know something and > disqualify it as not being true. Could you ellaborate?
How can you know something when it is false? "As you well know, the sky beneath my feet is yellow." Did you know the sky is beneath my feet? Did you know it was yellow? Is the sky beneath my feet yellow?
> <<I think you will find far more fertile ground elsewhere.>>Probably. > Looking at the spirit of most comments I have read in other threads NG, > it seems collaboration is not the main overall drive in this NG. Thank > you for pointing it out.
I think you will find collaboration here. But the collaborators are not in the habit of holding onto nonsensical statements.
The infertile ground I referred to is OO not the newsgroup.
> << When you write that an SQL table of degree 3 has two dimensions, > then > what you write is nonsense regardless of your belief.>>
> I have not written that anywhere (have not used degree). I am curious > however as to *what* exactly makes you believe that I said that.
I never accused you of misusing "degree". You used "dimensions" nonsensically.
> If you don't mind, I will use your example to clarify:
> ...Consider the following relvar
> T5: x,y,z
> ...then consider its SQL counterpart...
> create table s5 ( > x as integer not null > , y as integer not null > , z as integer not null > ) primary key (x,y,z)
> ...then consider the following view
> select x, y, z from s5
> ...my point is that the following possible output in one possible > representation of the relvar...
> 1, 2, 3 > 3, 5, 5
Since neither (1,2,3) nor (3,5,5) are points on a sphere of radius 5, I highly doubt that they will ever appear in any possible representation of the relvar.
> ..considering this output is a direct disk image implementation meaning > disk storage mechanism and in-memory representation in current SQL DBMS > are *physically* storing
You have not established that at all.
> Adress 1/ 1, 2, 3 > Adress 2/ 3, 5, 5
Again, this is not necessarily the case--not even for SQL as currently implemented by most vendors.
> I do not understand why you advocate the idea that this particular > physical implementation is anything else than bidimensional?
Why would I think a linear address space has more than one dimension? Why would you think the linearity of the address space says anything about the dimensionality of an SQL table?
<< When you snip as much as you do, it is harder for me to have a dialog.>> Communication through forums is not easy I convene. I am not accustomed to exchanges and jargons through NG.
I do not know what *snipping* exactly means. I have however been very clear into clarifying my position whether on a logical and physical layer. The fact of simultaneously considering both into argumentation does not mean I confuse them as you tend to imply.
<< In the RM, and in SQL, the logical model is what it is: multidimensional. This is true regardless of the physical implementation.>> I understand now the source of confusion in communication. I have made clear that I wished this thread would be about implementation but refering to logical requirements seems to be confusing.
I have never denied that RM or SQL are multidimensional. I just do not believe that current implementation of SQL are. And I have not heard any valid argument proving the opposite.
<< It might be easier if you picked one level, physical or logical, and stuck to discussing that. When you switch back and forth so quickly, our communication seems to break down.>> Thank you for this advice. I understand its wisdom. I will try to be more cautious.
<< You keep saying that physical representation is two dimensional. But that's not correct. Physical memory is one dimensional; it is a single line of memory from address 0 to address n.>> You are wrong. Most RAM components are two and three dimensional. (adress, columns and sometime blocks for 64 Kbit architecture)
<< If by "bidimensional" you mean that SQL is always implemented as a simple row store, this is not correct. There are products that are column stores. There are other hybrid approaches. It is not so simple.>> No by bidimensional I mean bidimensional in their adressing scheme (row vs columns). The only difference between simple row tore and column store is that they switch dimensions. Their adressing scheme remains logically bidimensional.
Which SQL DBMS products do you refer as being hybrid? column stored and simple row store? I suggest you check the following link from a friend of mine (Harry McKame) who participated in the initial implementation of System R. He has developed his own version of SQL because he understood the original limitations of current implementations.
Marshall wrote: > Cimode wrote: > > <<Okay; you're discussing the physical layer here. (Although your > > parenthetical remark is incorrect; the choice of a particular > > implementation strategy isn't what determines whether > > you have independence or not.)>>
> > You consider relvar and R-Table physical layer? Can't agree with that > > (must have missed something).
> When you snip as much as you do, it is harder for me to > have a dialog. You talked about physical concerns, which > I pointed out, and now you say you weren't discussing > physical concerns, but you've snipped the paragraph > I was responding to, which discussed implementation > and physical concerns.
> I'll try to be very clear:
> In the RM, and in SQL, the logical model is what it is: > multidimensional. This is true regardless of the > physical implementation.
> It might be easier if you picked one level, physical or > logical, and stuck to discussing that. When you > switch back and forth so quickly, our communication > seems to break down.
> > << No, I don't think that's correct at all. Physical memory is > > unidimensional;>> > > Please explain your point.
> You keep saying that physical representation is two > dimensional. But that's not correct. Physical memory > is one dimensional; it is a single line of memory from > address 0 to address n.
> If by "bidimensional" you mean that SQL is always > implemented as a simple row store, this is not correct. > There are products that are column stores. There are > other hybrid approaches. It is not so simple.
> > << Well, I wouldn't do that if I were you. I think your best bet is to > > study the existing literature on relational implementation. > > Read ten papers and see if you think OO has something > > useful to say.>> Thanks for the word of caution.(I appreciate) but I > > already started doing that. Diversifying sources helps too. ;)
Cimode wrote: > Marshall wrote: >> When you snip as much as you do, it is harder for me to >> have a dialog. > Communication through forums is not easy I convene. I am not > accustomed to exchanges and jargons through NG.
> I do not know what *snipping* exactly means.
[snip] In the above, I repaired some effects of your unusual snipping and quoting style.
Cimode wrote: > <<What's the substantial difference with repect to 'dimensionality' ?>> > Mainly that SQL current implementation are direct image implementation > which limits their ability to represent relvar adequately.
Hold on right there. No one is talking about implementation, much less about 'direct image implementation', whatever it is. Please state clearly what the difference is between two expressions describing the variable that can contain a three dimensional object (except minor syntactical pecularities).
>They can > only manipulate relvar on a representation per representation basis.
What's that supposed to mean ?
> <<See above, and what analogy do you have in mind ?>>Please read above. > A ruby's cube has 3 dimensions (width, length, depth).
So do both the relval and the SQL object descriptions. It's, like, a trivial observation.
> When you look > at one face of the cube you see only 2 dimensions. These 2 dimensions > are on possible representation of the cube.
Cimode wrote: > <<I am not certain I agree with that last sentence.>>Can you ellaborate > on that? What > do you have in mind?
> <<That's a different issue.>>You really think so? I would argue that > it is too closely related to to be ignored.
> <<However, that does not change the degree of a table and > does not change the fact that the degree is a direct measure of the > dimensions.>> Yes. So. I have never denied that. This is why I > made a distinction between SQL tables as they are implemented and SQL > tables as they should be represented. Do you have any idea onto how an > in memory SQL table footprint looks like on current SQL DBMS?
Clarification please: are you saying that direct image implementations are two dimensional because all the columns are adjacent to each other in a row? (If so, you're writing a very different language than the readers of your posts are reading.)
Cimode wrote: > << When you snip as much as you do, it is harder for me to > have a dialog.>> > Communication through forums is not easy I convene. I am not > accustomed to exchanges and jargons through NG.
> I do not know what *snipping* exactly means. I have however been very > clear into clarifying my position whether on a logical and physical > layer. The fact of simultaneously considering both into argumentation > does not mean I confuse them as you tend to imply.
Sniping too much: eliding too much of what others wrote when responding to their posts. Context is lost, confusion results.
By the way: what ever quoting style that is, it is hard to read.
<<I already elaborated. You simply omitted it from your excerpt. >> << I am not certain I agree with that last sentence. Of the dbmses that
have widely or deeply penetrated the market, SQL based systems are the best we have. There may or may not be better alternatives that are relatively unknown. >> I will take that as ellaboration. No disagreement here.
<< Since you removed all context of what I wrote, I no longer have any idea what we are discussing.>> Sorry I am not used to exchange on NG. Do not have the habits and jargons ;) (Excuse the confusion it may have produced)
<<Which is irrelevant, as I already explained.>> I reread your explanation but I am still doubtful about its relevance to the point of this thread. The main point in this thread is to exchange information on a physical standpoint as mainly. You are placing yourself mainly on a logical standpoint on which I do not believe we have a real disagreement.
<<How can you know something when it is false? "As you well know, the sky beneath my feet is yellow." Did you know the sky is beneath my feet? Did you know it was yellow? Is the sky beneath my feet yellow?>>I do not see an relevance in this analogy.
<< I think you will find collaboration here. But the collaborators are not in the habit of holding onto nonsensical statements.>> I hope so.
<< Since neither (1,2,3) nor (3,5,5) are points on a sphere of radius 5, I highly doubt that they will ever appear in any possible representation
of the relvar.>> I am not doing geometry. I reused your example to illustrate that if a specific SQL implementation *physical* representation of a relvar is bidimensional (because its body is only column/row represented) then it is clearly what defeats independence.
<<The infertile ground I referred to is OO not the newsgroup.>>OK. misunderstood.(apologies for that)
<< I never accused you of misusing "degree". You used "dimensions" nonsensically.>>I used *dimensions* in a mathematical sense. That certainly does not make it nonsense.
<<You have not established that at all.>> This is not formal theory formulation. I am trying primarily to exchange through a difficult media/ Doing the best I can .(know that I have been educating myself on Relational concepts based on *translations* from DATE, PASCAL, DARWEN which does not make it easy to exchange with English speaking audiences). I do not understand how such simple concepts are so troublesome to you.
<<Why would I think a linear address space has more than one dimension?
Why do you keep making me say what I do not say. I have never said that. in memory are not one dimensional only.
<<Why would you think the linearity of the address space says anything about the dimensionality of an SQL table?>> I have not said nor implied that. I am suggesting that the bidimensional (in a mathematical sense) aspect of a physical adressing scheme may be one of the cause for the lack of independence between logical and physical layer in current SQL DBMS.
> > <<I am not certain I agree with that last sentence.>>Can you ellaborate > > on that? What > > do you have in mind?
> I already elaborated. You simply omitted it from your excerpt.
> > <<That's a different issue.>>You really think so? I would argue that > > it is too closely related to to be ignored.
> Since you removed all context of what I wrote, I no longer have any idea > what we are discussing.
> > <<However, that does not change the degree of a table and > > does not change the fact that the degree is a direct measure of the > > dimensions.>> Yes. So. I have never denied that. This is why I > > made a distinction between SQL tables as they are implemented and SQL > > tables as they should be represented.
> Which is irrelevant, as I already explained.
> > <<Regardless of implementation, a sphere of radius 5 has three > > dimensions > > as does the set of integral points on a sphere of radius 5. The table > > s5 > > above has degree three and three dimensions: x, y and z.>> > > Yes. That's not the point.
> If you are trying to make a different point, I suggest you use words > that mean something else, then.
> > <<As a matter of fact, I do not know that because it is in fact not > > true.>> > > I don't understand this statement. How can you not know something and > > disqualify it as not being true. Could you ellaborate?
<<How can you know something when it is false? "As you well know, the sky beneath my feet is yellow." Did you know the sky is beneath my feet? Did you know it was yellow? Is the sky beneath my feet yellow?>>
> > <<I think you will find far more fertile ground elsewhere.>>Probably. > > Looking at the spirit of most comments I have read in other threads NG, > > it seems collaboration is not the main overall drive in this NG. Thank > > you for pointing it out.
> I think you will find collaboration here. But the collaborators are not > in the habit of holding onto nonsensical statements.
> The infertile ground I referred to is OO not the newsgroup.
> > << When you write that an SQL table of degree 3 has two dimensions, > > then > > what you write is nonsense regardless of your belief.>>
> > I have not written that anywhere (have not used degree). I am curious > > however as to *what* exactly makes you believe that I said that.
> I never accused you of misusing "degree". You used "dimensions" > nonsensically.
> > If you don't mind, I will use your example to clarify:
> > ...Consider the following relvar
> > T5: x,y,z
> > ...then consider its SQL counterpart...
> > create table s5 ( > > x as integer not null > > , y as integer not null > > , z as integer not null > > ) primary key (x,y,z)
> > ...then consider the following view
> > select x, y, z from s5
> > ...my point is that the following possible output in one possible > > representation of the relvar...
> > 1, 2, 3 > > 3, 5, 5
> Since neither (1,2,3) nor (3,5,5) are points on a sphere of radius 5, I > highly doubt that they will ever appear in any possible representation > of the relvar.
> > ..considering this output is a direct disk image implementation meaning > > disk storage mechanism and in-memory representation in current SQL DBMS > > are *physically* storing
> You have not established that at all.
> > Adress 1/ 1, 2, 3 > > Adress 2/ 3, 5, 5
> Again, this is not necessarily the case--not even for SQL as currently > implemented by most vendors.
> > I do not understand why you advocate the idea that this particular > > physical implementation is anything else than bidimensional?
> Why would I think a linear address space has more than one dimension? > Why would you think the linearity of the address space says anything > about the dimensionality of an SQL table?
