Re: Reminder, blatant ad

From: dawn <dawnwolthuis_at_gmail.com>
Date: 15 Feb 2006 14:03:10 -0800
Message-ID: <1140040990.447771.74920_at_o13g2000cwo.googlegroups.com>


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) 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 - 23:03:10 CET

Original text of this message