Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Neo <neo55592_at_hotmail.com>
Date: 2 Jun 2006 19:03:44 -0700
Message-ID: <1149300224.862586.229170@i40g2000cwc.googlegroups.com>


> DBD's data model is named TM. It's details are not being disclosed currently.
>
> Why would someone want to use a data management product with
> an undisclosed data model?

:) Because it is more general/flexible/systematic than other data models including RM and excels in applications where:

1) data structure is complex/variable
2) future data requirements are unknown
3) and minimum impact on schema/queries/code is desirable (ie AI-type
apps).

Actually the data model was described in cdt for several years and people like Alfredo and Bob concluded it couldn't possibly work.

> Anyhow, because I'm a n00b and want to practice I will play with that example. (Note I'm not trying to /convince you/ of anything. Your tenor suggests that is not possible. Here is my relational database:

I was hoping for one of the defenders of the faith :) Maybe one will step in later to assist.

> Here is my relational database:
>
> colors :
> name part color
> ---- ---- -----
> john skin black
> john hair red
> john hair blue
> mary skin white
> mary hair red
>
> textures :
> name part texture
> ---- ---- -------
> mary skin smooth
> mary hair silky
> mary hair smooth
>
> Now for me this is easier to reason about than the hierarchy presented on that page

In dbd, data shown in text, tree and grid are derived views of underlying data. Each view has its advantages and disadvantages and one particular view may be easier to reason with for a specific case. Did you also see the same data presented in the grid which appeared as follows?

person    name      skin                      hair
-----------  ----------  ---------------------  ----------------------
AutoID#   john        black                    red-blue
AutoID#   mary       white-smooth      red-silky-smooth

Since a script was not provide for the relational implementation, I will assume the underlying data is structured in two tables as shown above. As such, we can't even begin to make a valid comparison as the data in the relational implementation is not normalized where as there are no redundant represenation of things in dbd's. For example, in the relational implementation mary is represented in two tables and in multiple rows and db has no reliable method of knowing that they are the same. The only reliable mechanisms that allows a rmdb to guarantee they are the same is via normalization and key constraints. Dbd automatically "normalizes" data on the fly. Even though mary appears multiple times in the tree view, there is only one thing in the db which represents her.

Now suppose, we want to add a second person also named mary but with purple hair. Dbd handles this situation without restructuring the original data. The RM implementation above will require an overhaul. This is an example of how dbd's method of representing things is more general/flexible/systematic and less suspectible to future data requirements.

Until the RM implementation is totally normalized, I can repeat the above scenario over and over again where RM implementation will need to be restructured to handle new data, where as dbd won't since it is always "normalized" automatically.

> Finally, I would like to point out there may be flaws with the (undisclosed) DBD data model similar to the ones with other MV systems exposed by Bob Badour in his "red blue car" analysis from some time ago. He and others thoroughly demolished the MV advocates in that long thread.

Dbd doesn't suffer MV's flaw in implementing multiple values for an attribute (and I weclome the attempt to show it does). Among other reasons, MV is flawed because it can't provide data independent references to maintain integrity between similar values. The RM implementation above has a similar flaw between the multiple marys, but this situation is correctable in RM via proper normalization and key constraints.

Can you update the initial RM implementation to handle multiple person's with same name (ie mary with purple hair). He is how to do it in dbd (without changing existing data/structure):

(create hair instance (new))
(create (it) color (select+ color instance 'purple))

(create person instance (new))
(create (it) name (word+ 'mary))
(create (it) hair (and (select hair instance *) (select * color
purple))) Received on Fri Jun 02 2006 - 21:03:44 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US