OOOS

#**101**

"Tom Hester" <$$tom (AT) metadata (DOT) com> wrote

Quote:

Logic and mathematics are not the same. Read Gödel. Furthermore, the
definition of relation is different in logic from the one in mathematics.
That is why http://www.swif.uniba.it/lei/foldop/foldoc.cgi?relation gives
two definitions: one for logic and one for mathematics:
1. <logic> A way in which two or more objects are connected, associated,
or
related, or (at a different level) a polyadic predicate symbolizing such a
relation. See attribute, predicate logic

[Glossary of First-Order Logic]

2. <mathematics> A subset of the product of two sets, R : A x B. If (a, b)
is an element of R then we write a R b, meaning a is related to b by R. A
relation may be: reflexive (a R a), symmetric (a R b => b R a), transitive
(a R b & b R c => a R c), antisymmetric (a R b & b R a => a = b) or total
(a
R b or b R a).

These two definitions do not mean the same thing.

You are apparently ignorant of Codd's work proving the equivalence, which is
only one of the important theoretical results that is a direct offspring of
the relational model.

Quote:

"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote in message
news:403643a8.15899852 (AT) news (DOT) wanadoo.es...
On Fri, 20 Feb 2004 07:45:37 -0800, "Tom Hester" <$$tom (AT) metadata (DOT) com
wrote:

As usual, Bob is only about half right. He has given the mathematical
definition of relation but ignores its definition in logic, which is
clearly
applicable for Michael Groys:
1. <logic> A way in which two or more objects are connected,
associated,
or
related, or (at a different level) a polyadic predicate symbolizing
such
a
relation. See attribute, predicate
logic(http://www.swif.uniba.it/lei/foldop/....cgi?relation).

It is exactly the same as the mathematical definition. Logic is
mathematics.

Relations are the best way to associate objects in a database. Object
databases must be relational and RDBMSs must support user defined
types (classes).

It's rather simple if you are not a zealot.

Regards
Alfredo

#**102**

On Fri, 20 Feb 2004 13:06:22 -0500, "Bob Badour" <bbadour (AT) golden (DOT) net>
wrote:

Quote:

But in RDB objects are represented by set of facts

Relations, not objects!

I disagree with both of you. In an rdbms, object values are represented as
object values. Object classes are represented as object classes. Object
variables are represented as object variables. The only global variables
allowed are relation variables, which represent sets of related object
values.

Yes, my bad. I was sloppy.

Regards
Alfredo

#**103**

On Fri, 20 Feb 2004 10:08:01 -0800, "Tom Hester" <$$tom (AT) metadata (DOT) com>
wrote:

Quote:

2. <mathematics> A subset of the product of two sets, R : A x B. If (a, b)
is an element of R then we write a R b, meaning a is related to b by R. A
relation may be: reflexive (a R a), symmetric (a R b => b R a), transitive
(a R b & b R c => a R c), antisymmetric (a R b & b R a => a = b) or total (a
R b or b R a).

It is not completely correct. It should be a subset of the product of
n sets. Then it matches perfecty with a polyadic predicate.

IMO the reason of the confusion is that almost all the mathematical
studies about relations prior to Codd were restricted to binary
relations.

Regards
Alfredo

#**104**

Hester, you are ignorant and either obstinate or stupid. The relational
algebra is set theory, and the relational calculus is predicate logic.

The relation is the same in both cases. Dr. Codd proved the equivalence
decades ago, and that is only one of his very important proofs in
mathematics and logic.

Whether one calls it a set or a predicate, it is the same thing. Making
fatuous claims of some difference proves your profound ignorance of the
subject and nothing else. Given that I already provided you this answer, I
can only conclude either you lack the cognitive ability to understand me or
you simply refuse to listen.

"Tom Hester" <$$tom (AT) metadata (DOT) com> wrote

Quote:

The difference is that mathematical relations are defined on sets; but
logical relations are defined over objects, sometimes referred to as
individuals.
"Bob Badour" <bbadour (AT) golden (DOT) net> wrote in message
news:FKKdnW5Xy_rL0Kvd4p2dnA (AT) golden (DOT) net...
How did I ignore polyadic predicate? Other than the greek polyadic vs
the
latin n-ary, what is the difference?

In case you don't know, Codd proved the equivalence long ago.

"Tom Hester" <$$tom (AT) metadata (DOT) com> wrote in message
news:8fffc$40362ba2$45033832$5903 (AT) msgid (DOT) meganewsservers.com...
As usual, Bob is only about half right. He has given the mathematical
definition of relation but ignores its definition in logic, which is
clearly
applicable for Michael Groys:
1. <logic> A way in which two or more objects are connected,
associated,
or
related, or (at a different level) a polyadic predicate symbolizing
such
a
relation. See attribute, predicate
logic(http://www.swif.uniba.it/lei/foldop/....cgi?relation).

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote in message
news:PaKdnZQf840V14PdRVn-vw (AT) golden (DOT) net...

"Michael Groys" <michaelg (AT) alzt (DOT) tau.ac.il> wrote in message
news:bvl4e2$88g$1 (AT) news (DOT) iucc.ac.il...

Bob Badour wrote:
Depends on what you mean by OO DB.

This is very good question.
Actually I worked only with regular databases.
In addition I wrote ODBC driver for some database project.
By OO DB I mean the database that contains objects of different
types
and relations between them.

You seem to misuse the term relation. A relation is a set of
n-ary
tuples.
Is this what you mean?

I suspect you really meant to say 'objects of different types
with
pointers
among them'.

May be I indeed misuse it, but what I actually meant is that the
OO
DB
have to manage some connections/associations/relations between
objects
and/or basic types.

As I mentioned previously, a relation is a set of n-ary tuples. Why
do
you
persist in misusing the term? Connections and associations sounds an
awful
lot like pointers to me.

How it is organized is not important for the concept.

I disagree. The logical data model has the utmost importance.

It can be pointers or n-ary tuples or something else.

If it is n-ary tuples, it is a relational dbms. If pointers or
'connections', I suspect you mean a network model or hierarchic
dbms.

As you know regular relational databases
contain tables with some predefined set of fields per each
entry.

No, I don't know that. A relational database is a set of true
fact
statements.

When you perform sql query - you access some columns of some
tables.

Are you suggesting that SQL defines the relational model?
Ridiculous!

Using a relational dbms, one derives new true fact statements from
the
database using the rules of symbolic logic.

#**105**

Quote:

The difference is that mathematical relations are defined on sets;
but logical relations are defined over objects,
sometimes referred to as individuals.

If you choose to see math and logic as different things, then there is
a difference. If you choose to see both math and logic as merely
things, there there is no difference. The choice you make is neither
right or wrong

#**106**

"Tom Hester" <$$tom (AT) metadata (DOT) com> wrote

Quote:

With apologies to Little Big Man, you know the words but you don't know
how
to use them. Codd proved no such thing!

See the 1972 paper and Codd's reduction algorithm as mentioned in the
following tribute:
http://www.acm.org/sigmod/record/iss...ributeCodd.pdf

You can respond however you want to the newsgroup, but I have decided you
are terminally ignorant. Unless someone with only a little less sense than I
have responds, I won't see it. Toodles

Quote:

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote in message
news:a9mdnSRsfOTE06vdRVn-uA (AT) golden (DOT) net...
"Tom Hester" <$$tom (AT) metadata (DOT) com> wrote in message
news:a3cd1$40364d02$45033832$7730 (AT) msgid (DOT) meganewsservers.com...
Logic and mathematics are not the same. Read Gödel. Furthermore, the
definition of relation is different in logic from the one in
mathematics.
That is why http://www.swif.uniba.it/lei/foldop/foldoc.cgi?relation
gives
two definitions: one for logic and one for mathematics:
1. <logic> A way in which two or more objects are connected,
associated,
or
related, or (at a different level) a polyadic predicate symbolizing
such
a
relation. See attribute, predicate logic

[Glossary of First-Order Logic]

2. <mathematics> A subset of the product of two sets, R : A x B. If
(a,
b)
is an element of R then we write a R b, meaning a is related to b by
R.
A
relation may be: reflexive (a R a), symmetric (a R b => b R a),
transitive
(a R b & b R c => a R c), antisymmetric (a R b & b R a => a = b) or
total
(a
R b or b R a).

These two definitions do not mean the same thing.

You are apparently ignorant of Codd's work proving the equivalence,
which
is
only one of the important theoretical results that is a direct offspring
of
the relational model.

"Alfredo Novoa" <alfredo (AT) ncs (DOT) es> wrote in message
news:403643a8.15899852 (AT) news (DOT) wanadoo.es...
On Fri, 20 Feb 2004 07:45:37 -0800, "Tom Hester"
$$tom (AT) metadata (DOT) com
wrote:

As usual, Bob is only about half right. He has given the
mathematical
definition of relation but ignores its definition in logic, which
is
clearly
applicable for Michael Groys:
1. <logic> A way in which two or more objects are connected,
associated,
or
related, or (at a different level) a polyadic predicate symbolizing
such
a
relation. See attribute, predicate
logic(http://www.swif.uniba.it/lei/foldop/....cgi?relation).

It is exactly the same as the mathematical definition. Logic is
mathematics.

Relations are the best way to associate objects in a database.
Object
databases must be relational and RDBMSs must support user defined
types (classes).

It's rather simple if you are not a zealot.

Regards
Alfredo

#**107**

Bob Badour schrieb:

Quote:

"Adrian Veith" <nospam (AT) veith-system (DOT) de> wrote in message
news:c14ft1$9r3$02$1 (AT) news (DOT) t-online.com...

Michael Groys schrieb:

Alfredo Novoa wrote:

Michael Groys <michaelg (AT) alzt (DOT) tau.ac.il> wrote in message
news:<c0for5$rn7$1 (AT) news (DOT) iucc.ac.il>...

In any OO standalone/precompiled application one needs to have some
representation of objects in memory in order to perform some
operations on them.

In standalone applications it is true, but in information systems
applications are not alone. If you use a DBMS you don't need to load
the database objects in the application's memory to perform operations
on them.

A trivial example:

delete from customers

The customers will be deleted without being loaded in the client's
memory.

Thus the rest of your post does not make sense.

Regards
Alfredo

Dear Alfredo,
I said OO application.
Now please describe me one more trivial example.
You have in database some drawable object with name "object".
It can be or line or point or arc or picture or curve or text or arrow.
You are asked to draw it.
How you will do it.

I will do it in following way.
Object object = database.find("object")
object.Draw();

Your turn.
Michael.

Hi Michael,

in our web-site www.db-gonzales.de (under downloads) is a simple example
(GDemo) which shows how to draw objects out of a dbGonzales database
*without* creating an instance of these objects.

main loop for drawing the objects looks like this:

tb:= FDatabase.Storage.CreateTableInstance(cGDEMO);
// create an instance of the table where the objects are stored
qy:= TGdfFilteredTableOp.Create(tb, [],
TfComp.New(tb.BaseClass.FieldByName('ParentID'), TvVariant.Val(Null),
[cvEQ]) //*
);
// look only for the top level objects
// * don't bother the query-compiler with a simple query.
// if you prefer a textual query you can write:
// tb.CompileFilter('ParentID is null')
// but in an time critical procedure, you can do the parsing and compile
// a query expression directly
qy.Start;
while qy.Step do begin
obj:= TPaintObject(tb.CurrentInterface);
// return an interface to current object
// if no interface is registered for the current object the
// function returns nil
if obj <> nil then
obj.PaintTo(FBitmap.Canvas, ZeroPt);
// call the virtual Paint function of the interface
end;

the GDemo demo shows, that this method of accessing the objects stored
in the database is performant enough to animate several thousands of
objects in real-time and view the same animation on all clients which
access the same database.
the limiting factor in this demo is not the data-access but the slow
drawing procedures of windows. if i comment out the calls to the windows
drawing api, i get much higher frame rates (accessing the objects,
calling the virtual PainTo procedure and preparing the geometric = 20%
-> drawing = 80%).

And you think this is an advantage to Alfredo's one-liner? Yikes!

Yikes is the wrong word. You meant "Bob der Jeck" - Helau und Alaaf.

Carneval is over Bob. Take off your fools costume.

#**108**

"Lee Fesperman" <firstsql (AT) ix (DOT) netcom.com> wrote

Quote:

Carl Rosenberger wrote:

Lee Fesperman wrote:
If I were to use SQL to help me retrieve "my car" from a database, and I do the
same query twice, how will I know that the object already exists in memory and
that the result of the query should simply be a reference to the car instance that
already exists? Since I can't do that without assistance, I will never be able to
use the first equality statement mentioned above and my application is going to
have to be "coded" to take that into account.

B.equals(C) is the accepted method in Java; B == C is very rarely correct (which
vitiates your argument).

I think you are in the wrong newsgroup, Lee.
This is comp.databases.object.

And the world rejoices that you are not in charge of c.d.o!

In true object-oriented applications "==" comparisons are very commonly used. You may
like to ask the developers of your database engine or look through the code of it for
yourself for occurences of "==".

The default implementation of equals() for all objects, if is not overridden:

public boolean equals(Object obj) {
return (this == obj);
}

True. Modern JVMs will eliminate the method call, so there's no reason not to use
equals() in this case. However, the default equals() method is not appropriate for data
objects, which we are discussing.

If the class overrides equals(), for whatever need there may be, "==" is a lot more
efficient. Consider the following class:

class Person{
String firstName;
String lastName;

public boolean equals(Object obj){
if(obj instanceof Person){
Person cmp = (Person)obj;
// null problems and accessor methods skipped to make the example short
return firstName.equals(cmp.firstName) && lastName.equals(cmp.lastName);
}
return false;
}
}

Obviously person1 == person2 will be a lot faster than person1.equals(person2).

Now, this implementation of equals() is more appropriate for a data object. You didn't
really make the example shorter since your comment takes as much space as a null test.

As to accessor methods, 2 comments:

1) Often, you would reference the fields directly for an equals() implementation in the
class.

2) Modern JVMs will optimize away the method call for accessors, so there's no reason
not to use them.

This is basically a case of over optimizing.

One last note: you didn't write the return above as,

return firstName == cmp.firstName && lastName == cmp.lastName;

... because that is incorrect.

Further to the above simple example there there may be deep class structures
where equals() delegates to a couple of hundred objects.

Exaggeration to make your point? That sounds like a poorly designed object structure.

Spend some time news:comp.lang.java.programmer and learn how to use Java properly
(also accepted coding conventions).

I don't think you are serving your cause well with arrogance. You will turn off
potential customers.

Your opinion matters little, since you use misinformation to confuse.

From mail discussions with Corey (a potential customer of our product) I know that
he does know quite a lot about Java and about the requirements for his product.

His knowledge of Java doesn't show. He is capitalizing variable names, contrary to
accepted coding conventions.

It's an example for crying out loud and it is perfectly legitimate. Maybe in your
sloppy world you need to use an overridden .equals() method to determine equivalence
of two "data" objects. In the ODBMS world, the database guarantees that if
I acquire the same object from two different paths, it will be the same object, period!
Thus A == B will return true. In your case, it won't, and you will have to override
the .equals method on every class that you write.

Good luck with that.

Quote:

--
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

OOOS

comp.databases.object comp.databases.object

Re: OOOS - 02-20-2004 , 12:12 PM

Re: OOOS - 02-20-2004 , 03:47 PM

Re: OOOS - 02-20-2004 , 03:57 PM

Re: OOOS - 02-20-2004 , 04:51 PM

Re: OOOS - 02-20-2004 , 05:02 PM

Re: OOOS - 02-20-2004 , 05:10 PM

Re: OOOS - 02-25-2004 , 04:43 AM

Re: OOOS - 04-09-2004 , 02:12 PM