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

Neo wrote:
Keith H Duggar:
> > 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).

First, your peculiar placement of smilies in this post and others comes across to me as condescending. Is that your motivation?

Anyhow, how can one verify your claims 1-3 if the data model is hidden? Is there a way to analyze a hidden data model? Or must we spend time inferring the data model from your particular DBMS interface?

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

Interesting, can you point me to some subjects or links?

> > 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.

Sorry to disappoint you. Though I have no idea what "faith" you are referring to. Is it the same "faith" one needs to believe claims about an /undisclosed/ data model?

> 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?

No I overlooked that initially.

> Since a script was not provide for the relational
> implementation,

I'm getting a little confused here. Remember I'm a new to this lingo. What is a "relational implementation"? Is that a synonym for database or DBMS? Is what I presented (copied below) correctly called a 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

> 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 representation 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.

I don't understand this language. What are "things"? Why is mary a thing? In the model above isn't mary just a value in domain name? What do you mean by "knowing that they are the same"? What is "they"? What redundancy are you referring to? If the we take (name part color) and (name part texture) as the primary keys for colors and textures, then how is the database not normalized?

> The only reliable mechanisms that allows a rmdb to
> guarantee they are the same is via normalization and key
> constraints.

As far as I can see the above database is normalized.

> 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.

Again what is a "thing"?

> 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.

Hmm ... well your(?) dbd seems to automatically generate an unique ID, yes? A7FB etc? That was something I just missed in the website example originally. Trivial to correct the design to include this. RDBMS products regularly provide such automatic unique ID's if you want them as well.

colors :
person name part color
------ ---- ---- -----
A7FB john skin black
A7FB john hair red
A7FB john hair blue
AD2E mary skin white
AD2E mary hair red

textures :
person name part texture
------ ---- ---- -------
AD2E mary skin smooth
AD2E mary hair silky
AD2E mary hair smooth

There we go. Now it matches what you have in your example (unless "dir", "item", and "clsDir" are somehow meaningful) and at the same time solves the "same name" problem. Note that the primary keys are now (person part color) and (person part texture) to maintain 2NF.

> 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.

What scenario can you repeat? Please do so within this example.

> Dbd doesn't suffer MV's flaw in implementing multiple
> values for an attribute (and I weclome the attempt to show
> it does).

It's easier to explore potential problems with a data model if it is actually disclosed. By the way, isn't MV a type of data model? How does a data model "implement" something? Or do you mean "dbd doesn't suffer from the flaw in most/all current implementations of MV models"? And here we would be talking about DBMS and not data models or databases correct?

> Among other reasons, MV is flawed because it can't provide
> data independent references to maintain integrity between
> similar values.

What do you mean by "similar values"? What is a data independent reference?

> 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.

If there are "multiple marys" then what is /a/ mary? All I see are values, tuples, and relations up there. Is this the "thing" concept again?

> 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):

Yes, it is updated above to include the person attribute I originally overlooked (it was small and grayed-out) upon first inspection of the (your?) example page. And yes you can add as many "marys" as you want now without changing the exiting structure (schema?).

• Keith --

PS. Not that, as pointed out before, I'm new to this. So if I've made basic mistakes please excuse me cdt. Received on Sat Jun 03 2006 - 10:24:30 CEST