![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
#3
| |||
| |||
|
|
Seun Osewa PS: I would post a follow-up to this e-mail once google groups users can see it. |
#4
| |||
| |||
|
#5
| |||
| |||
|
|
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. |
#6
| |||
| |||
|
|
Read Date's and Darwen's _The Third Manifesto_, the book and not the 1995 paper, for a sound type inheritance model. |
#7
| ||||
| ||||
|
|
"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. |
|
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. |
#8
| |||
| |||
|
|
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 |
|
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 |
|
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 |
#9
| |||
| |||
|
#10
| |||
| |||
|
![]() |
| Thread Tools | |
| Display Modes | |
| |