dbTalk Databases Forums  

Introducing PlayDB (The Model, The Language, The DBMS)

comp.databases.object comp.databases.object


Discuss Introducing PlayDB (The Model, The Language, The DBMS) in the comp.databases.object forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Seun Osewa
 
Posts: n/a

Default Introducing PlayDB (The Model, The Language, The DBMS) - 10-09-2003 , 02:31 PM






Hi,

I want to thank people on these groups for the educated responses to
my enquiries in the thread "Dreaming of Redesigning SQL". There is
much to learn, speaking for myself, but the brain does not agree to
stop _working_ while learning because in a good life learning would
and should never stop.

I want to set up this thread to discuss some ideas I have for building
a system (The Data Model, The Language for Data Definition and
Manipulation, The Reference DBMS Implementation) and to get helpful
insights, helpful criticism, etc. I believe we would all have fun
doing this. Google tells me that some of the people in these groups
have done some truly notable things and i am glad to have this limited
access to you.

Disclaimer: Its meant to be more of an intellectual journey which aims
to lead somewhere that is useful in the practical world. I would post
follow-up messages indicating what I have so far. I have absolutely
no plans for implementing the system anywhere except my mind, unless
by reasoning over it in this public forum one comes to the conclusion
that its worth implementing.

Thanks,

Seun Osewa
PS: I would post a follow-up to this e-mail once google groups users
can see it.

Reply With Quote
  #2  
Old   
seunosewa@inaira.com
 
Posts: n/a

Default Re: Introducing PlayDB (The Model, The Language, The DBMS) - 10-09-2003 , 08:10 PM







Hi,

The name 'PlayDB' is an attempt to flame-proof the thread from comments like,
"Hey, this is not the way to develop something _serious_" Afterall,
its only PlayDB!

Going through thread archives on the three groups (and sites like
dbdebunk.com) I find that a lot of arguments occur over definitiona of basic
things like "relational", "data model", etc. MySQL AB may use "relational" to
mean "able to process SQL queries" and the authors of the third manifesto may
mean someone else. All should be well as long as each speaker explains his
usage of each word. Words tend to be "overloaded" in real life and if the
multiple meanings contiue long enough, they become the right meanings
*sigh*.

I have found these online glossaries/dictionaries to be particularly
interesting, but I would like to know your opinions:
Ibm glossary of computing terms:
http://www-3.ibm.com/ibm/terminology/goc/gocmain.htm
American National Standard Dictionary for Information Systems:
http://www.ncits.org/tc_home/k5htm/ANSDIT.htm

Please point me to any other sources of information. Its easy to miss some
things when there are millions of pages to search, despite google
assistance.

I believe at the beginning of the process it might be difficult to separate
between descriptions of the model, the language, and the implementation
because they affect each other so much but eventualy it should happen.

Regards,

Seun Osewa

----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse (AT) newsone (DOT) net

Reply With Quote
  #3  
Old   
seunosewa@inaira.com
 
Posts: n/a

Default Re: Introducing PlayDB (The Model, The Language, The DBMS) - 10-09-2003 , 08:13 PM



In article <ba87a3cf.0310091131.2bd3b6e7 (AT) posting (DOT) google.com>, Seun Osewa
Quote:
Seun Osewa
PS: I would post a follow-up to this e-mail once google groups users
can see it.
Hi,

The architecture I have been thinking of involves storing both the data and
the business logic on the server. "Users" never actually use the query
language (Let's call it PL/PlayQL, which would be procedural) directly. They
instead connect to the PL/PlayQL programs running on the server, via a simple
request/response interface.

The language, while strictly procedural, would include a savepoints feature
that will allow the server to roll back execution in the case of mysterious
errors and try again from last savepoint. SO the effects of program
execution can always be reversed until a savepoint. And because the program
is managed by the server the programs do not stop running abruptly when
clients disconnect. In fact one can have long-running processes on the server
and it becomes something like an OS (pending: unfuzzification of these
statements).

Summary: processes using "PL/PlayQL" running on database server having
flexible access to data. Client programs connect to these processes and
communicate using simplified protocols that are totally independent of the
underlying database. All business logic is implemented on the server.
PL/PlayQL as a language implements savepoints and can be rolled back to last
savepoint. Communication with client actually takes place at savepoint
boundaries (cause it cannot be reversed).

Seun Osewa


----- Posted via NewsOne.Net: Free (anonymous) Usenet News via the Web -----
http://newsone.net/ -- Free reading and anonymous posting to 60,000+ groups
NewsOne.Net prohibits users from posting spam. If this or other posts
made through NewsOne.Net violate posting guidelines, email abuse (AT) newsone (DOT) net


Reply With Quote
  #4  
Old   
Seun Osewa
 
Posts: n/a

Default Re: Introducing PlayDB (The Model, The Language, The DBMS) - 10-09-2003 , 09:20 PM



Based on my own observations, I would like to define a class as:

"A set of Objects/Entities percieved to have certain similar
properties."

In this definition there is no notion of hierarchy because that's the
way it is in real life. A square is a rhombus, a rhombus is a
parallelogram. A square is also a rectangle, which is not a rhombus,
but is a parallelogram. So we would have difficulty defining one
"superclass" for square. Then of course a parallelogram could turn
out to be a rhombus on resizing, a rectangle could become auitable to
join the group of squares on resizing, etc. And I think this is just
the case in real world that the classES an object belongs to can also
be dynamic. And when you look at the relational model, well, it
requires you to choose a type for each item of data.

What if an object could be a member of any arbitrary set of classes?
What if this mapping of object to class was totally dynamic? It
reminds me of interfaces in Java programming where an object can
export an infinite number of interfaces, only that of course all this
is dome at compile-time. Things could be come more
complicat....err... interesting!

Seun Osewa.

Reply With Quote
  #5  
Old   
Bob Badour
 
Posts: n/a

Default Re: Introducing PlayDB (The Model, The Language, The DBMS) - 10-09-2003 , 09:33 PM



Read Date's and Darwen's _The Third Manifesto_, the book and not the 1995
paper, for a sound type inheritance model.

"Seun Osewa" <seunosewa (AT) inaira (DOT) com> wrote

Quote:
Based on my own observations, I would like to define a class as:

"A set of Objects/Entities percieved to have certain similar
properties."

In this definition there is no notion of hierarchy because that's the
way it is in real life. A square is a rhombus, a rhombus is a
parallelogram. A square is also a rectangle, which is not a rhombus,
but is a parallelogram. So we would have difficulty defining one
"superclass" for square. Then of course a parallelogram could turn
out to be a rhombus on resizing, a rectangle could become auitable to
join the group of squares on resizing, etc. And I think this is just
the case in real world that the classES an object belongs to can also
be dynamic. And when you look at the relational model, well, it
requires you to choose a type for each item of data.

What if an object could be a member of any arbitrary set of classes?
What if this mapping of object to class was totally dynamic? It
reminds me of interfaces in Java programming where an object can
export an infinite number of interfaces, only that of course all this
is dome at compile-time. Things could be come more
complicat....err... interesting!

Seun Osewa.



Reply With Quote
  #6  
Old   
Seun Osewa
 
Posts: n/a

Default Re: Introducing PlayDB (The Model, The Language, The DBMS) - 10-10-2003 , 03:01 AM



"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Quote:
Read Date's and Darwen's _The Third Manifesto_, the book and not the 1995
paper, for a sound type inheritance model.
Thanks, Bob. I was able to find the relevant chapter here:
http://www.hughdarwen.freeola.com/Th...web/CHAP13.pdf
And a presentation based on the same topic:
http://www.hughdarwen.freeola.com/Th...moti.paper.pdf

The scheme seems too rather complicated :-( but I am looking at it
still.

What I am considering here is to get rid of the notion of type
inheritance altogether and allow each object to simply be (or not be)
a member of any combination of recognized classes as long as it
satisfies basic requirements of each class it wants to a member of.

One implication of this is that object creation queries will not be of
the form INSERT RELATION_XXX SET ATTRIBUTE = .... Instead it will be
like CREATE OBJECT WITH ATTRIBUTES .... ... ... [MEMBER OF CLASSES
PPP, QQQ, RRR]. Objects are inserted into "the system" and not into
tables.

In the relational model the attributes served as means of
differentiating one tuple within a relation, but in the model I am
tending towards the attributes of an object must be able to
differentiate it from all other objects on the system. That's a
challenge.

Looking at a class as simply a subset of objects in the system, if it
can be implemented efficiantly, offers maximum flexibility and yet we
can still create an inheritance model (hierarchical or DAG) by
defining certain _constraints_ such as:
A. "every object that joins class CIRCLE must also join class ELLIPSE"
B. "every object in MANAGERS should also be in EMPLOYEE"

So if the company now takes up a policy of allowing non-employees to
be MANAGERS no problem. We simply drop rule A. If Mathematicians
redefine an ELLIPSE to no longer include CIRCLE we simply drop rule A
and tell every CIRCLE to no longer be an ellipse.

Of course this means in the implementation special structures to store
info about which object is in what class would be necessary. But I
think its a more natural model of reality.

Since types are dynamic, it turns out that the only way to point from
one object to the other is to have an typeless pointer. I will reread
some article I stumbled accross about what's wrong with OIDs. Yuck.
With this "dynamic typing" maintaining indices will be very messy.

I am also thinking of reducing most joining/querying to a process of
class definition.

Instead of select * from EmpTable where department = "home";
I may simply define an Employees_at_Home class and add all employees
at home to that class and set up rules that automatically add newly
created employees to the class when their department = "home" and
remove them when the case is different.

Seun Osewa


Reply With Quote
  #7  
Old   
Bob Badour
 
Posts: n/a

Default Re: Introducing PlayDB (The Model, The Language, The DBMS) - 10-10-2003 , 08:20 AM



"Seun Osewa" <seunosewa (AT) inaira (DOT) com> wrote

Quote:
"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

Read Date's and Darwen's _The Third Manifesto_, the book and not the
1995
paper, for a sound type inheritance model.

Thanks, Bob. I was able to find the relevant chapter here:
http://www.hughdarwen.freeola.com/Th...web/CHAP13.pdf
And a presentation based on the same topic:
http://www.hughdarwen.freeola.com/Th...moti.paper.pdf

The scheme seems too rather complicated :-( but I am looking at it
still.

What I am considering here is to get rid of the notion of type
inheritance altogether and allow each object to simply be (or not be)
a member of any combination of recognized classes as long as it
satisfies basic requirements of each class it wants to a member of.
Whether one has a strongly typed computational model or an untyped
computational model, values have types. You are arguing for an untyped
computational model without any kind of argument or justification.


Quote:
One implication of this is that object creation queries will not be of
the form INSERT RELATION_XXX SET ATTRIBUTE = .... Instead it will be
like CREATE OBJECT WITH ATTRIBUTES .... ... ... [MEMBER OF CLASSES
PPP, QQQ, RRR].
This is non sequitur. The former does not imply the latter. All you have
done with the latter is remove the ability to express n-ary relations among
values and impose a huge cognitive burden on users who must know the full
set of types they want each value to have.


Quote:
Objects are inserted into "the system" and not into
tables.
Thereby crippling the system. Without relations, all one has is a
hodge-podge of disjoint values without any means to derive new facts from
them.


Quote:
In the relational model the attributes served as means of
differentiating one tuple within a relation, but in the model I am
tending towards the attributes of an object must be able to
differentiate it from all other objects on the system. That's a
challenge.
You apparently make one or both of the great blunders, and then you
basically restate POOD.

[remainder of nonsense snipped]

When proposing a new data model, one must address the issues of data
independence, semantic expressibility, referential integrity and data
manipulation among others. The proposed data model must at least match the
relational model on all of those points. Your proposal fails even to
approach the relational model on any of those points.




Reply With Quote
  #8  
Old   
Seun Osewa
 
Posts: n/a

Default Re: Introducing PlayDB (The Model, The Language, The DBMS) - 10-10-2003 , 11:01 AM



Hi,

In response to Bob Badour:
Quote:
When proposing a new data model, one must address the issues of data
independence, semantic expressibility, referential integrity and data
manipulation among others.
Believe me I am working on it one step at a time. And also learning a
lot of new phrases. And being sharpened up, I hope. This is why I am
taking this approach of posting openly. This is work in progress and
I appreciate you helping me figure out some relevant next steps

"Referential Integrity": Each pointer-to-object has a single class of
objects it is allowed to point to and on being pointed at a new object
checks are made to see that the the object being pointed to is a mem-
ber of the required class, at least.

"Semantic Expressibility": I assume you mean the ability to specify
suitably complex queries to the DBMS, right? Working on the query
language. Will post some thoughts about this soon.

"Data Independence": The separation of data from the programs that use
the data. (http://www.pcwebopaedia.com/TERM/D/d...ependence.html)
Why? So that both programs and the data can be changed independently
of each other. But in reality data consists not only of simple con-
stant attributes like 'Seun's Birthdate'. It may also consist of
algorithms like "formular for tax calculation in 1993 November". I
suggest this is one reason why "enterprise" databases end up with
a lot of stored procedures and triggers. So what I am suggesting
is a suitably smart server-side query/procedural language (may
include OO code organisation features) which provides access to
the database and which is used to build long-running processes on
the server which connect to client programs through application-
specific protocols which need not change for the lifetime of the
application even though the 'database' is changing.

What I have done here is: to split "application" into two. Take
the business logic which is really inseparable from the database
way and move it into 'server-side'. Put the presentation logic
in 'client-side'. Define an app-specific communication protocol
As long as the protocols are adhered to I have separation of
'server-side' and 'client-side' which is really what we wanted in
the first case if I am not mistaken. Which is what "enterprise"
applications are attempting to do with 3-tier designs and exten-
sive stored procedure libraries.


"Data Manipulation": ... I guess once I start to talk about the
query language the possibilities will become clearer. I would
not agree that my proposed scheme is "typeless". i'd rather say
it has dynamic typing. How exactly attributes of the objects
will be exported to each interface i have no idea but I am look-
ing into the implementation of OO "interfaces" for inspiration.
One advantage I may have is the intended support for algorithms
in the database. Then such algorithms may be used to read or
write data from a given object being considered as being a mem-
ber of a particular class.

He also wrote:
Quote:
One implication of this is that object creation queries will not be of
the form INSERT RELATION_XXX SET ATTRIBUTE = .... Instead it will be
like CREATE OBJECT WITH ATTRIBUTES .... ... ... [MEMBER OF CLASSES
PPP, QQQ, RRR]. <me
This is non sequitur. The former does not imply the latter. All you have
done with the latter is remove the ability to express n-ary relations among
values and impose a huge cognitive burden on users who must know the full
set of types they want each value to have.
Users do not need to know all the types. As I said the admin can simulate
a hierarchy or "DAG" type structure by creating constraints that automa-
tically add an object to a class if the user specifies it to belong to
what the DBA sees as a subtype. In PlayDB Proposal 1(heh) the concept
of type inheritance or relationship between classes is wholly in the
mind of the DBA and is enforced by constraints which can be relaxed at a
later date if need be. i still think its a smart concept if one ignores
implementation issues.

And also:
Quote:
Objects are inserted into "the system" and not into
tables.
Thereby crippling the system. Without relations, all one has is a
hodge-podge of disjoint values without any means to derive new facts
from them.
Please tell me exactly what sort of facts cannot be derived and I will
try to explain how in fact they can be derived. The devilish part will
be the implementation. Already studying adaptive block rearrangement
and log structured data storage for possible answers. I apologize in
advance that thought about the implementation may tend to affect discu-
ssions about the model: if two approaches are equally powerful but one
seems easier to implement its natural to choose the one that's going
to be easier to implement cause IMHO an unworkable model is useless.

What do you think? I like the idea that my spontaneous presentation
gets to be dissected line by line.

Best regards,
Seun Osewa


Reply With Quote
  #9  
Old   
Seun Osewa
 
Posts: n/a

Default Re: Introducing PlayDB (The Model, The Language, The DBMS) - 10-10-2003 , 12:29 PM



"Bob Badour" <bbadour (AT) golden (DOT) net> wrote:
SELF is a classless programming Language, claims to be object oriented
http://www.wikipedia.org/wiki/Self_computer_language
http://research.sun.com/self/language.html
http://research.sun.com/research/sel...ial/index.html

A lot of ideas about making a typeless Object-Oriented database system
workable would be learned. i am on it.

Thanks a million,
Seun Osewa

Reply With Quote
  #10  
Old   
Seun Osewa
 
Posts: n/a

Default Re: Introducing PlayDB (The Model, The Language, The DBMS) - 10-11-2003 , 01:11 PM



Hi,

I guess maybe my approach to the whole "PlayDB" issue has been wrong,
as Christopher Browne said, and a newsgroup is not the best place.
Probably I should be at a corner somewhere working on the ideas and
like Patrick O'Brien only come here occasionaly to announce
milestones, get the already developed ideas reviewed, etc.

How do you suppose I could get *one* person who is free for the
discussion of such ideas? Tip:

A programming partner once told me "all you want to do is work on
ideas and I do not have the time" and we had to part ways. So i
wonder if there is someone else here who would like to participate in
this idea-feast with me in a private forum and use it as a means of
_learning_ about the state of the art in database systems and perhaps
come up with a plan for implementing a DBMS (if and only if we find
reaso to go in that direction?)

To Lee Fesperman: Sadly the only way I get to learn things like this
(which I am, by the way, certainly not encouraged to learn in the
country I am based cause there is no money involved) is to put myself
under the impression that I am _doing_ something special with the
knowledge. Typically, the "something special" would be found to have
been implemented by someone else and there would be no need to do it
and the knowledge would remain.

I believe I am not the only one in this group who thinks this way.
Does anyone want to come to a private forum to discuss a model for
data management systems?

Having said all this, you guys have been wonderful in answering
straightforward enquiries and with the slightest encouragement I will
keep posting new thoughts that come to mind for criticism/review (that
is the whole point).

Regards,
Seun Osewa :-(

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.