Data Model implementation pointers

Hi All,

Anyone have links to a good tutorial for folks used to "thinking in RDBMS terms" that explains how to implement non-trivial OO data models in GemStone (or similar-type technology) using typical cases like 1-to-1, 1-to-many, many-to-many relationships?

As I think about my data model it's both highly hierarchical and highly relational. I don't suppose it's easy to implement in either purely relational or purely OO terms. I understand there are a bunch of different ways to achieve the same thing, but what I'm looking for is an initial starting point for translating what I know into what I am learning.

My intuition tells me OO is the way to go, for maximum expressiveness of the richness of the model I've designed. Chunking it up the RDBMS way creates a bunch of extra concerns; however it does have a few advantages.

Basically I want to make the switch from an over-reliance on relational data storage concepts to a more OO implementation that preserves the beauty of the model, in all its complexity.

Any pointers will be greatly appreciated.

- Bob

Bob,

Here is Ramon Leon's answer to a similar question[1], which may help you get started.

Dale

[1] http://gemstonesoup.wordpress.com/2009/05/19/gemstone-101-making-the-leap-from-rdbms-to-persistent-objects/

----- Original Message -----
| From: "bobcalco" <[hidden email]>
| To: [hidden email]
| Sent: Tuesday, February 7, 2012 2:50:55 PM
| Subject: [GS/SS Beta] Data Model implementation pointers
|
| Hi All,
|
| Anyone have links to a good tutorial for folks used to "thinking in
| RDBMS
| terms" that explains how to implement non-trivial OO data models in
| GemStone
| (or similar-type technology) using typical cases like 1-to-1,
| 1-to-many,
| many-to-many relationships?
|
| As I think about my data model it's both highly hierarchical and
| highly
| relational. I don't suppose it's easy to implement in either purely
| relational or purely OO terms. I understand there are a bunch of
| different
| ways to achieve the same thing, but what I'm looking for is an
| initial
| starting point for translating what I know into what I am learning.
|
| My intuition tells me OO is the way to go, for maximum expressiveness
| of the
| richness of the model I've designed. Chunking it up the RDBMS way
| creates a
| bunch of extra concerns; however it does have a few advantages.
|
| Basically I want to make the switch from an over-reliance on
| relational data
| storage concepts to a more OO implementation that preserves the
| beauty of
| the model, in all its complexity.
|
| Any pointers will be greatly appreciated.
|
| - Bob
|
| --
| View this message in context:
| http://forum.world.st/Data-Model-implementation-pointers-tp4366689p4366689.html
| Sent from the GLASS mailing list archive at Nabble.com.
|

Thanks, Dale.

I'm looking for one or two practical examples. For example, Person, Address, Org. A person can have many Addresses, and an Address can house many People. At any one given point in time, the Address is only occupied by a specific set of people. A Person can have a primary residence, and any number of other Addresses they own. Similarly, a Person can work for many Orgs, and an Org can employ many people. Moreover, an Org can have many Addresses where it does business. We'd like to preserve not just who lives and works where, but see in the past who has ever lived or worked where. And just to throw some more complexity into the mix, I'd like to capture relationships between People, mainly familial ones, but also loose friendships.

So we have 3 primary entities but LOTS of ways they are related. I haven't even suggested the inheritance model for Person or Org. (For example, both can be a LegalEntity, and a Person may or may not be a User in the system...).

I'd like to know how seasoned Smalltalkers approach creating Model classes for this kind of specification, keeping in mind the system would like to use any of them as a root domain object (i.e., given a list of each entity type, when a user selects a specific entity, show a tree view of its relationships).

THis it seems to me should be relatively easy in an OODBMs but still, there are habits of thinking to be corrected for the new paradigm, and a need to master the right idioms, which is why I ask. :)

- Bob

At 08:59 08/02/2012, bobcalco wrote:

I'd like to know how seasoned Smalltalkers approach creating Model classes
for this kind of specification

Hi Bob, all,

I'd suggest having a look at the followings:

Refactoring to Adaptive Object Modeling: Entity Relationships and Accountability
http://www.codeproject.com/Articles/10587/Refactoring-to-Adaptive-Object-Modeling-Entity-Rel

Also at:
http://adaptiveobjectmodel.com/

And specifically at:
http://www.adaptiveobjectmodel.com/WICSA3/ArchitectureOfAOMsWICSA3.pdf

Hoping this helps,
Cheers,
Reza Razavi
http://linkedin.com/in/razavi

Bob,

Am 08.02.2012 um 08:59 schrieb bobcalco:

This is certainly doable in an OODBMS because there is a lot of flexibility. And there are multiple way you could solve it. The way that is best is the one that suits the usage of your model. I don't think there can be the "best generic" answer to your entity-reliationship based construct.
Coming from an SQL based environment there are only queries. And queries are bidirectional meaning you have on query that might give you both access directions (which Bs are related to A _and_ which A has a relationship to B).
In an OODBMS you get navigation as additional way of accessing data. The referenced objects of an object you can get by accesing the references. This can be seen as a query to a table of type X with some id. On the other hand the navigational access does also partition your data. Meaning the access to an address should stay the same no matter how many addresses there are. In an SQL environment it makes a difference if the address table has 100 or 1.000.000 entries.
But using navigational access to data does not give the reverse direction. So if A has a reference to B you can access B from A but not the other way round. If you need this there will be some ways to achive this.

So much to the context switch by changing the environment :) You can see there are things to gain and things to loose. By learning that doing OO in an OODBMS gives you a lot of flexibility. That means also that you probably don't need to design everything upfront. The structure of your model is changed so easily regarding to schema migration that you might evolve your model when the use cases are set. With use cases in your hand you can design your model to suit it best. IMHO the decision towards are model that suits your use case is also a decision that might solve some performance problems already.

Hope this makes sense to you somehow,

Norbert

On 08/02/12 2:59 AM, bobcalco wrote:
>
> THis it seems to me should be relatively easy in an OODBMs but still, there
> are habits of thinking to be corrected for the new paradigm, and a need to
> master the right idioms, which is why I ask. :)

IMHO, the difference comes down to: with an OODB there are
implementation decisions that have to be made, whereas with an RDB, many
implementation decisions are already determined by the RDB.

To illustrate, consider class A and class B, which are related by
relationship R1 in a one-to-many from A to B. Typically, an RDB
implementation would use a foreign key in B table. You could then, from
a given A instance, find the corresponding B's; or, similarly, from a
given B instance, find the corresponding A.

The implementation decision already made for you is that all
relationships can be navigated in either direction, at a the
unchangeable cost of a join done by the RDB (which can be optimized
somewhat with indexes).

Now, in an OODB, a typical way to implement a 1-M relationship is to use
a collection on the 1-side. In this case, each A would have an instance
variable, "r1values" say, which held the collection of B's. There is now
the choice of what kind of collection to use for r1values - it could be
a Set, OrderedCollection, or SortedCollection, whatever was best suited
for traversing all the B's. Also, there is a choice whether or not the
B's should have an instance variable, "r1value" say, which references
the corresponding A instance - but at the cost of having to maintain the
back reference during updates.

Hope that helps.

Bob,

As others have said, you have many options and the OO contribution is flexibility. You can follow a typical RDBMS model, with lots of top-level collections (like tables) or you can take advantage of the fact that OO allows you to have a collection as an instance variable. And, as others have said, the cost of change is low enough so that while some thought is reasonable before you start, you don't really have to get it right up front.

To the extent that you are concerned about performance, you should look at GemStone indexes (discussed in the programming guide). Basically, you can create an identity index (fast lookup based on #'==') or an equality index (fast lookup based on #'<', #'<=', #'=', #'>=', or #'>'). A limitation of GemStone/S 64 Bit indexing is that it cannot reach through collections in instance variables. That is, if you have a collection of persons and a 'phone' instance variable with a single string (for example), then you can index on phone. But if you have a 'phones' instance variable with a collection of phones, then you cannot index on phone. To to that you need a separate collection of phone usage objects with one named instance variable being a person and another named instance variable being a phone number. This top-level collection can have indexes on both attributes and allows you to find all the phone numbers for a person and all the persons for a phone number. This collection can duplicate information already stored in a person object (which requires additional maintenance) or you can do the index lookup in an accessor method in the person object.

Note also that a Dictionary provides quick lookup based on hashing so you could have a Dictionary with the key being the phone number and the value being a collection of people with that phone number.

-James

On Feb 7, 2012, at 2:50 PM, bobcalco wrote:

Hello,
  I have one class, a subclass of WAComponent, that is showing up twice in my browser.
One of these classes has all of the subclasses for all of the components I have built. The
other class is not showing any subclasses.

  The two classes appear to be identical, at least, I can see no difference in their names, instance
variables, or methods. Is this a browser bug? Should I worry about this?

  Also, should I be concerned about migrating instances of this class? There are three different versions
in the class history. I don't see why any instances of a WAComponent class would be held onto, but I don't know. I tried
to migrateAllInstances to class history last but failed because:

"An attempt to execute a method that requires an abort or prevents further commits would result in lost data"

when Gemstone attempted an allInstances.

  Thoughts?

  Regards,

  Larry

Lawrence,

I also ran into this issue, most often when Gemtools breaks down during code loading (out of mem for example).

There's an easy solution for this. See this post:

http://forum.world.st/Resolve-script-for-double-classes-visible-in-Gemtools-td3654222.html



On 08 Feb 2012, at 22:35, Lawrence Kellogg wrote:

On Feb 8, 2012, at 4:46 PM, Johan Brichau wrote:

> Lawrence,
>
> I also ran into this issue, most often when Gemtools breaks down during code loading (out of mem for example).
>
> There's an easy solution for this. See this post:
>
> http://forum.world.st/Resolve-script-for-double-classes-visible-in-Gemtools-td3654222.html
>
>

  Johan,
  Thanks once again! Yes, that took care of my problems.

  Any idea if instances of WAComponent are being held onto my Seaside?
I would assume that they would all get garbage collected, as I create them but
do not hold any references to them in a session.

  Regards,

  Larry