Re: One Ring to Bind Them

Marshall:

"Marshall Spight" <mspight_at_dnai.com> wrote...

[snipped]

> So I read all of your comments, and I couldn't figure out what
> they meant. I didn't see any clear answer to whether MV supports
> relationships besides containment. In fact you evaluated that stament
> as "not true but not exactly false." I have no idea what that means.

One of the primary impediments to communication is a different use of words and definitions. From a non-RD model perspective a relationship exists when the properties of two pieces of data can be defined as having an aspect or quality that connects them as being or belonging or working together or as being of the same kind <the relation of time and space>. This seems obvious to me but I do not use the RD model, or mathematical, definition.

So, there exists a relationship between vendors and invoices. Containment has nothing to do with that relationship, except the relationship is contained within the database.

What exactly is this relationship and how is it stored? I can store the invoice#s within the vendor in the vendor table. This defines a relationship in the MV model (although there are a number of other ways to do so). How is this relationship going to be exposed? An example would be to create a virtual field definition in the vendor table so that when asked, will deliver the list of invoices associated with this vendor and any data contained within the invoice table.

The phrase "...not true but not exactly false..." was intended to reflect my desire to avoid being argumentative or didactic. My apologies for being obtuse and misleading. :-)

> > One of the interesting aspects of the
> > MV model is the data and relationship is stored in the database.
>
> Uh, same with RM.

I'm sorry to say this is another of those "yes but not really" observations. The relationship is stored in the relational database but not really like it is stored in the MV database. This is true because the MV model treats everything like regular data; unlike the RD model. As such, everything is stored in the database tables right along with all the other data; names, addresses, relationships, metadata, functions, constraints, stored procedures, application code, compiled code, etc. All MV tools, like RD tools, are available for these additionally defined data; it's just stored with all other data in the exact same formats.

What makes this different is only that these tables are usually part of the database structure of the production data. So, you'd have tables for constraints, stored procedures, relationships, metadata, application code, and data all within a single database structure built for an application. The RD model would normally keep this kind of data separate from the production data within its own special system tables.

However, once again, the stuff stored is the same. It's just where its stored in relation to the normal everyday production data that's different.

> > The models we use create "stupid" tricks. It's the models that create
the
> > constraints to make some tricks stupid and others smart. An RM "stupid"
> > trick may be an MV smart move; and visa-versa. However, most design and
> > development are constrained by the base delivery model: server vs
> > client/server.
>
> I disagree. There are specific well-documented and *fundamental*
> disadvantages to managing integrity in applications instead of centrally.
> This is independent of MV vs. RM vs. whatever.

Don't forget, these "well documented" disadvantages revolve around the RD model, as its structure requires a different dance. If a dbms stores integrity constraints in the dbms, and the application is stored and runs in the dbms, then it makes little difference whether the integrity constraint is in or out of the application, as the application is located centrally in the dbms. I would point out that from this perspective it is wise to modularize the application so other applications can utilize the defined constraints.

> > Let's reconcile a bank account. We need a primary account table and a
> > transaction table in both models. However, in the MV model we don't
need
> > anything more than this. We will define the keys of the transactions to
> > include the account#, so the account table can (and probably will)
contain
> > the ref# of the transactions. The transaction key would look like:
> > Account# and transaction#.
>
> You're going to reuse transaction numbers in different accounts?
> And you're also going to include the transaction number in
> the account table? That kind of redundancy leads directly
> to data corruption.

Ah, excuse me? One reuses check#s in different accounts all the time. One reuses invoice#s for different vendors all the time too. To include the transaction# in the account table is to do nothing different than needs to be done anyway to define a relation; A > B and B < A. Redundancy? Storing the transaction#s in the account saves having to store the "transaction to account" relationship, as it is already defined by the transaction key. So this reduces redundancy. Data corruption? No different than anywhere else. Synchronization code performs the same task in all dbms products, although sometimes differently.

> > > I don't know how to measure the idealness of a solution, so I have
> > > no particular claims about whether the RM is ideal or not.
> >
> > I sit in a corporate VP meeting and discuss this with them and they with
me.
> > We all see the same thing. I'm not the odd man out here. In addition,
I
> > can almost directly translate their vast knowledger to the dbms design
and
> > relationship definition. I think this is good!
>
> How is this a response to what I wrote? It sounds like what you
> are saying is "I work in the computer industry."

I'm not taking a stand here claiming the RD model is bad. Nor am I stating that other models are necessarily better. I'm merely pointing out there are other methods and tools and dbms models that work.

My point is the nomenclature, syntax, and concepts within the MV model are specifically modeled after those of business. Business people feel at ease working with the model because of its business friendly terms and concepts. That's why a lot of the MV modeling is done in a rapid development structure directly with business people.

> > They really do. They do primarily the same things. We're not talking
> > nuclear reactors and cigarettes. :-)
>
> Okay, how do you map a relational table like this into MV:
>
> create table Tri
> (
> a int,
> b int,
> c int,
> unique(a,b),
> unique(b,c),
> unique(a,c)
> );

A good example of the point I was trying to make, and have made before, about deconstruction/reconstruction. To a business person this is complete nonsense. However, it isn't nonsense to make sure a group of values are not duplicates or to make sure that certain fields are certain data types.

So, for instance, it is important that all invoice#s for a particular vendor are unique (we certainly wouldn't want to pay the same invoice twice). In the MV model the key is _not_ part of the data set but is part of the key (I would read a dataset using the key as the unique identifier). Thus both models do the same thing but a little differently. Other fields can be constrained. However, they're not constrained in the syntax of the table creation statement. They're done differently. So I can say any invoice must have a unique invoice# and a unique creation-stamp.

> > > If by this you mean that you can implement these features by
> > > hand-writing application code, then I don't consider that any
> > > achievement. I can say the same thing about some Java code and
> > > a hashtable, but it's not a good solution.
> >
> > Yes and no.
>
> This kind of answer is hard to work with. It's much easier to understand
> you when you give me a straight answer. Saying "yes and no" is worse
> than not responding, because it adds confusion.

I can understand your frustration. But it is true. You can write application code to implement these features. This code isn't at all one monolithic .exe. Remember, the application code sits inside the dbms just like any other data so its proximity to the datastore is significantly closer than in the RD model. A simple application may contain a thousand executables and a vast portion of the application is probably nothing more than functions that enforce integrity constraints, relationships, business rules, etc. So a function or API can be written and used by the application code just like an .OCX or .dll or .exe can be used. I would call this written in the application but, in the RD model this could easily be defined as a separate API residing on the application server serving any application wishing to use its functionality.

> > You can always hand write code in an applicaton. You can also
> > store the code in the dbms as triggers, constraints, relations, etc.
The
> > difference is that the RD model does some things one way and the MV
model
> > does some things the other way.
>
> Remember when I asked you to "be specific?"

I can set a trigger to enforce integrity within the bank account table so if a bank transaction is cleared, the uncleared reference to it within the bank account table is removed. So, right here I've set both a trigger and constraint on a relation at the same time. I know the RD model accomplishes the same task but differently.

> > The MV model is much more
> > application-centric. This is only bad when working with the RD model,
where
> > this is defined as bad (or "stupid"). Most things are done the same
though.
>
> No, it's bad for more fundamental reasons. If you don't enforce
constraints
> centrally, then integrity support becomes ad-hoc and
application-dependent,
> so one application might fail to enforce a constraint. A constraint that
> isn't enforced centrally is a constraint that won't necessarily hold.

I cannot emphasize this enough; the MV model is located centrally! The application server and dbms server reside within the same environment, on the same machine. Therefore, all constraints are enforced centrally. The centralized application APIs can be called from outside the application. Additional constraints can be developed to provide service to more than one application and to meet ever-changing requirements.

> Is this supposed to be a response to my earlier paragraph? Because
> I don't see the answer to my question about "can MV do ON DELETE
> RESTRICT" anywhere. Can it? What relevance does lock contention
> have to my question?

The answer is an emphatic yes. But not by saying: "ON DELETE RESTRICT"; unless one wants to utilize the SQL functionality within the dbms. More like:

:select table with no defined_constraint :delete table

> So, is that a "yes?" Are you saying it *is* possible to enforce a
> constraint centrally?

Remember, the constraints are stored centrally, as is the application APIs, custom business rules, relationships, functions, data, metadata, etc. So not only is it possible to enforce constraints centrally but it is required, and assumed from this model's perspective.

> > Rule one in life: never say never. Rule two in life: never say I can
do
> > everything. :-)
>
> It sounds like you don't understand Turing completeness. Also note
> that I didn't say "everything." I said "anything that can be computed."
> And I stand by my statement that BASIC can compute anything that
> can be computed; it is a Turing complete language. This is not
> the same thing as saying that it is a good language, though.

There is a lot in the universe I don't understand. I understand the word tautology, though. :-)

My tendencies are to accept imperfections and deal with them rather than think I'm correct, if only within my limited definition of what correct is.

> I appreciate you're trying to help me understand, but I'm
> having trouble following your posts. It seems like you
> quote me, then respond, but the response, while interesting
> isn't a response per se but you talking about something else.
> I get lost.

And here I was thinking I was answering your queries directly, albeit in a slightly different perspective. Perhaps my writing skills, and clarity of thought, will improve with time. :-)

Bill Received on Thu Jul 08 2004 - 09:48:43 CEST