Re: Reminder, blatant ad

From: <michael_at_preece.net>
Date: 15 Feb 2006 17:56:00 -0800
Message-ID: <1140054960.557834.265990@g44g2000cwa.googlegroups.com>

dawn wrote:

> Jan Hidders wrote:
> > dawn wrote:
> > > Jan Hidders wrote:
> > >
> > >>dawn wrote:
> > >>
> > >>>OK, then I'm pretty sure there are no such administrative features that
> > >>>can be performed on most commercial databases today that require a
> > >>>change to the logical data model.
> > >>
> > >>?? Most of them allow me to add indexes w/o changing the logical model,
> > >>or change clustered indexes to non-clustered ones, for example.
> > >
> > > ? Yes, that is what I was saying...? It was perhaps convoluted
> > > wording, so maybe you read it wrong?
> >
> > Ah, yes I did. But then, depending on what you define as "the logical
> > model", your observatoin is besides the point. This is not what
> > distinguishes DBMSs that feature physical data independence from those
> > that don't.

>

> For this purpose we can just talk about the application code that
> interfaces with the database. I have not seen any physical database
> changes that have prompted changes to the application dabase code
> (CRUD) or metadata, other than possibly some data source hard-coding.

>


> > For example, in the extreme case where there is no physical

> > data independence and the logical and physical model therefore coincide,

> > the only way to change the physical model is by changing the logical
> > model,

>

> Can you think of a a specific customer requirement for their software
> (likely related to an ility) that can be handled by an RDBMS (or
> SQL-DBMS) but not by these products where the physical model more
> closely aligns with the logical model?

>

> > and so even in that extreme case there are no separate
> > administratieve features that require a change to the logical model.

>

> OK, so we are not looking at a required change to the physical model
> prompting a change to the logical model while that is how I had
> understood why there was a requirement for data independence.

>

> My reason for asking is that I believe there must be some advantage
> that an RDBMS software solution has over an MV solution related to this
> data independence (because I'm pretty sure that folks would say that MV
> does not have data independence)

You can do what you like with Pick. PickBasic applications read data and access it as part of an ordered list - part of a delimited string. REC<1,2,3>, for instance, accesses the 3rd subvalue in the 2nd multivalue in the 1st attribute of a record. The "1", "2" and "3" can also be by reference rather than by value - so the "1" could be ProductCode, for example, and ProductCode could be assigned or equated to "1" elsewhere. Suppose you have a legacy application that's been running for many years and the code is littered with these direct references. This appears to run counter to the concept of data independence - but it ain't necessarily so. All you have to do to achieve data independence in this scenario is call a subroutine to obtain REC rather than READ it directly. What goes on in the subroutine that delivers REC to your application is entirely up to the developer. It might be sourced from a single "record", or "item", in a single file (typical) or it might be "compiled" from various sources. The more sophisticated development environments have parameterised options for controlling this data abstraction - so that the developer need not change any program code at all in changing the database design. Try googling CDP for "Data Abstraction Layer" if you want more details.

On the subject of the distinction between the physical and the logical :- I reiterate that the clear demarkation that exists in the SQL world, where the SQL engine clearly seperates one from the other, is absent in Pick. Pick is entirely logical.

Cheers
Mike.

> and I haven't figure out what it is.
> I'm hoping to understand it well enough that I could explain it to
> another MV person who does not have any background with the RM. I
> would like it to be in terms of a requirement (even if a quality, ility
> requirement) that can be met by an RDBMS but not by an MV system.

>


> > > Any ideas on a VSAM example of where a physical model change would

> > > prompt a logical data model change?  (that was at the end of this

> > > message)

> >

> > Well, if the fact that your data is stored in VSAM files is part of the
> > logical data model,

>

> I didn't, but I can see where that could be a valid way to view it.

>

> > then if you would change that to, say ISAM files,
> > then you would have to change the logical data model.

>

> So is data independence about data sources and having a language for
> the interface to the dbms that can be used for multiple databases? If
> you decided to point your COBOL or Java Oracle application at OpenQM
> (an open source PICK database openqm.com) you wouldn't exactly be able
> to do that without changing your application either. Does that mean
> that Oracle does not have data independence (no, I didn't think so).

>

> I clearly still don't grok this data indie thing. I don't know who
> (the end user, the developer, the system administrator, the dba) is
> impacted by this problem that is solved by an RM approach to data
> independence nor how it is solved. I'd like figure out an example of
> where the lack of data independence bites a Berkeley DB, Cache', MV...
> developer, for example.
>
> Thanks. --dawn
Received on Wed Feb 15 2006 - 19:56:00 CST