Re: Reminder, blatant ad
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 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,
> and so even in that extreme case there are no separate
> administratieve features that require a change to the logical model.
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