Re: Good Books on MultiValue Databases

Chandru:

Thanks for top-posting. :-)

Bill

"chandru murthi" <cmurthixyz@xxxxxxxxxxxxxxxxxx> wrote in message
news:FHlri.3016$id4.200@xxxxxxxxxxx
Hmmm, Trisha, one bottom post which requires one to wear out one's mouse
finger to read, followed by an eminently sensible top post. There's
"trying to stir up controversy"!

Chandru-thanks-for-top-posting-Murthi

"Trisha Ford" <trisha.ford@xxxxxxxxx> wrote in message
news:1185733519.245589.104860@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Jul 29, 11:09 am, Trisha Ford <trisha.f...@xxxxxxxxx> wrote:
On Jul 28, 12:39 am, Tony Gravagno

Wow! Folks, I apologize for that last post. I don't know how that
all got added but looks like somehow my reply text got quite
confused. I don't know how to delete that so please ignore it -- my
reply below:

Trisha




<address.is.in.po...@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Trisha Ford wrote:
So I don't think I was trying to claim to be an authority at all
there.

It looks like we're on the same page. I tend to see "this is what I
know so this is the way it is" comments in these forums all the time
and I just took this opportunity to make an observation. Nothing
outside of this was intended.

However, in the end regardless of whether
converting manually or using a tool, ultimately the end result is
still the same and you are, in fact, "re-architecting your entire
database". That is, either you are, or your tool is.

Well, yeah, a migration is a migration. If you completely migrate
your data, schema, and rules into a completely different environment
then it must be restructured. What I was reading from your comments
(and similar comments from others from time to time) is that a
migration "necessitates" a lot of manual mapping. This isn't
"necessarily" correct considering the various solutions I proposed for
either schema mapping or using SQL against existing databases where
SQL can be run against a virtual schema definition. (Maps that look
relational vs physical relational structures.)

Again, since MV
data is by definition in violation of the 12-Rules of true RDBMSes
(no
new info there, right?), the database structure when converting from
an MV environment to an RDBMS actually does require re-architecting.

I'll buy that to an extent. Your point is simply that MV is not
relational. No disagreement.

Once again your comment about Codd borders on another topic which I'll
tackle, (and I'm not saying you're saying this) that MV is somehow
invalid because, so they say, it doesn't fit Codd's rules.

Ok I see -- Let's backup: The person who wrote the original question
stated he was an Oracle person who's now inherited a Pick-type MV
database. So bear in mind that was the audience I was trying to
address. He also stated he would like to get some un-biased
information/documentation. So I don't believe I've made any value-
based statements as to my opinion regarding true 12-rule RDBMSes
versus Multi-Dimensional DBMSes anywhere. So given this -- not to
belabour the point, but a conversion/migration from an RDBMS to
another RDBMS (ie: Sybase-Oracle; Oracle-SQL Server; SQL Server-
Sybase), given the structural mapping is basically the same, would be
far easier than going from a Multi-Dimensional to a true 12-Rule
RDBMS, like Oracle in this case. Why? Because, by definition, the
structures are so inherently different. I wasn't making any judgement
on better or worse, just making a statement there, and from a purely
physical data-structure perspective.

Now, again having come from originally Pr1me Information/Primos and
PICK environments (also UV, UD, ARev, etc.) myself and now living in
the RDBMS world (12-rule Def), I will definitely say that I appreciate
both for the different benefits each has that the other may not (or
may attempt but not do such a good job as the other at). After
spending more than 10 years in the Pick-type world - as a Systems
Specialist, Developer/Analyst, you name it (I used to read the Pr1me
system architecture guide for fun, ok?), trust me I do not love
RDBMSes more than Pick.

Yes, by and large you're right - RDBMS people do tend to debunk MV.
Rest assured you'll not ever be seeing that from me.


As always, the very first (make that "zeroth") of Codd's rules stacks
the deck by stating "the system must qualify as relational". That's
like saying all motor vehicles must be fueled by gasoline which makes
it illegal to drive an elecric car on a roadway designed for motor
vehicles. No reflection on you at all Trisha, but relational people
tend to debunk MV (and XML and object and post-relational) data models
with this sort of circular rhetoric. The TPC benchmarks disqualify
non-relational databases by explictly defining how the relational
tables will be defined - um, if we don't have relational tables then
we can't possibly create a "valid" benchmark.

Let's take a look at a couple of Codd's other rules:

Rule 1 "All information in the database is to be represented
in one and only one way, namely by values in column positions within
rows of tables."
Well now if a "better" database ever comes along is it invalid
because it breaks this rule? Yup. Codd wrote his rules specifically
to defend his position on relational databases. Somehow this got
warped over the years to imply invalidation of anything that didn't
fit the definition.

Rule 3: "The DBMS must allow each field to remain null (or
empty). Specifically, it must support a representation of "missing
information and inapplicable information" that is systematic, distinct
from all regular values..."
Different RDBMS platforms support Null differently. Does that
make them non-relational or invalidate them as relational? Given the
definition of null, of course MV doesn't make this distinction on its
own, but with reference to my comments on how important business rules
are, we maintain referential integrity in MV not as a built-in part of
the DBMS, but the dbMS which includes a DB allows us to do this at the
code level. Similarly we're allowed to handle nulls as we see fit,
and many applications are coded to recognize the difference between
"no data" and "data is empty string". So because we use the tools in
management system, rather asking the management system to manage
itself, do we really violate this clause?

Rule 4: "The system must support an online, inline, relational
catalog that is accessible to authorized users by means of their
regular query language. That is, users must be able to access the
database's structure (catalog) using the same query language that they
use to access the database's data."
It seems this rule is really two in one: (a) users must
authenticate to get rights to access data, and (b) data and schema
must be accessible via the same query language. We can restrict user
access via login and command line lockouts. And we can say "SORT DICT
FNAME" as easily as we say "SORT DATA FNAME". Looks to me like we're
as compliant as anyone else...

I could go on about each one but I'll spare you more detail. (Haha,
funny thing for me to say.) It's possible to cite various RDBMS
products that by design or flaw do not conform to some of Codd's
rules. It's similarly possible to show that the capabilities of the
MV Database __Management_System__ allow us to Manage our data in a
manner consistent with most if not all of Codd's rules. The
distinction of the symantics may be lost in my inept ramblings here
but I think it's important that we have the freedom to make or break a
good app, and this is where relational people confuse open
(freedom/liberty) access with lack of ability. That is - we can,
though sometimes _do_not_, write code to enforce good relational
practices, but they say we _cannot_. This is why people throw Codd in
our faces, because their definition of the managment system is that
the system manages the data, but our definition is that we manage the
data using the system.

Whoa - Whoa there big fella! Hold on there babalouie...

Again... no particular fan of Cobb's here. Also, as I alluded to in my
last email -- while one Can define relationships in RDBMS DBs, in my
experience I have found that in the majority of times I do not see
relationships implemented (FK constraints, etc.) by and large in the
database Most people do Not want to deal with having to manage all
the cascading and maintenance headaches of allowing the RDBMS to
maintain those relationships 'automagically'. (Which frankly always
leaves me scratching my head thinking, "...and you paid how much for
this RDBMS product?" ...but I digress) Since relationships Can also
be defined in MV Dictionaries... well again, you're kinda preaching to
the choir here.



When computers were first created people feared they would control the
world, and science fiction is full of machines that make slaves of
man. While we all look at this as silly fantasy it's amazing how much
people rely on the machines to do things like data management for us
and how sternly they frown upon those of us who prefer to have more
control - because we enjoy such freedoms. Our choice to use software
which allows us these freedoms is criticized with references to these
rules of Codd which insist that the machine not only do something for
us but do it the way this one guy wrote oh so many years ago. The
Pick model has been slighted as being old and therefore wrong simply
on the premise that Codd wrote his rules after Pick. This is just
another example of the lack of logic some people employ to justify
their positions.

I'm not saying Codd's rules are necessarily wrong, that Pick is
better, that Pick is relational, etc. That's not the argument I'm
making here. I'm saying it's only valid to cite Codd when you're
trying to decide how conformist a relational database is to relational
rules, not when you're trying to validate whether or not a data model
is suitable for its intended business tasks.

Again, Trisha, I know you were just saying MV is different enough to
warrant some major changes.

I say this with the possible exception being that if you were not
using Sub-Values anywhere in your MV database to begin with, then you
may not need to re-architect in that case. Although clearly that
would be a great waste of the MV features in the first place.

Not necessarily. I think most applications I've seen actually do not
make use of sub-values. One reason is that the data isn't accessible
to most query processors. Another reason is that the logic is just
too complex and it promotes "hot shot" coding where a bit of (ahem)
normalization is actually better for maintainability.

Yah - you know I thought about my statement on sub-values after
writing my post. Actually, as I'm sure you're aware even Multi-values
violate the 12-rules by definition. Now I've never met Codd, but I
did have the pleasure of meeting *** Pick on numerous occasions
before his passing. Still remember the time he Finally spoke at one
of our Pr1me Information conferences after reaching a licensing
agreement with Prime at the time... and even despite *** falling off
the podium, I will say that man's recovery was no less than admirable
- he didn't miss a beat!


Then again I can't remember the last time I've seen relational key-
constraints actually implemented in any of the RDBMS DBs I've
supported in the last (I'm not telling how many years). >:-)
Keyword
there being that I have "supported", not architected.

That's funny considering the major focus people put on the RI aspects
of the relational model- can you explain this a little more?

Excellent point as well on getting sucked into the
"hey let's re-engineer our application on the fly" during conversion
efforts. That would fall into your basic Scope-creep though, yes/no?

What's interesting is how many smart people get completely fooled by
the sheep's clothing worn by the scope-creep wolf. Everyone knows the
BASIC rules need to be modified but why do so many of these projects
so grossly underestimate the time it will take to get the logic right
in the new environment - and so grossly overestimate the competence of
the people doing this work when they have so little understanding of
how it all worked in the first place? I'm referring to the "let's get
rid of the (cheap) MV people and hire a bunch of (expensive) people
(who haven't worked for years with the app) to do the re-write. One
solution to these disasters (I concede, from my comfortable arm chair
looking back with 20-20 to critique managers who I don't know) is to
ensure that there are people on-hand who understand the logic of the
existing application, and ensure that these people have the power to
veto/defer changes to that logic until the project is complete.

I'm working on a big project with a client right now where it would be
easy to try to make the software do more, as long as we're in there
doing a lot of other stuff. I don't think this one will creep but I'd
certainly recognize the signse and jump on it before it happens. LOL
- I'll let you know in a couple months how that theory works.


Yup - the old, "Hey I know! While we're in here anyway, why don't we
just... " Yes, I too am often amazed when watching people step onto
that old slippery slope. And as a 'techie', I must admit I've been
sorely tempted by the "here's my big chance to fix that old code that
I've been wanting to fix for years now" devil-on-my-shoulder, myself.
Now coming from more a management/consultant perspective, I do try to
keep the scope-creep bug down to a minimun.

I think my whole point was that conversion is not as easy as it might
appear at first-glance, may not make the most sense from a duration
and/or cost perspective, and should really be thought through before
diving in - for the reasons you've stated as well as those I have.

Yup, and I'm sorry I've been so verbose and potentially argumentative
in my agreement with you. :)

(Gosh I gotta stop doing this) ... again
TG@ blahblahblahNebula-RnD.com

What?! No comment on my "Sybase rules" statement??!

Bummer. :-)

Trisha

Nah, everyone is entitled to their opinion.

Ok, just so I'm clear... the one statement I was actually *Trying* to
get some controversy on is entirely overlooked and/or acceptable.
Hmmm... I'll have to try harder next time!


Regards,
T




.