Re: Reminder, blatant ad

Jan Hidders wrote:
> dawn wrote:
> > Jan Hidders wrote:
> >
> >> dawn wrote:
> >>
> >>> Jan Hidders wrote:
> >>>
> >>>> dawn wrote:
> >>>>
> >>>>> I'd like to better understand data independence in terms of
> >>>>> functionality.
> >>>>>
> >>>>> [...]
> >>>>
> >>>> It means that you can make some changes in the physical model
> >>>> w/o having to change the logical model. Note that this is
> >>>> different from what you just said because you were talking
> >>>> about the logical model.
> >>>
> >>> I thought that was what I was saying in the first answer. How is
> >>> this different?
> >>
> >> The version of the DBMS tool doesn't change. You should be able to
> >> change the physical model w/o changing the tool.
> >
> > Surely some software somewhere (the OS, the DBMS?) is getting a new
> > version in order to make for this "change"?

>

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. I'm sure they don't all have every feature (clustering, for example).

> >>> [...] Why would you think that a change in the physical model of
> >>> a non-relational DBMS (e.g. PICK) would require reworking the
> >>> logical model?
> >>
> >> This is not necessarily true for all such systems but in many of
> >> those the logical and physical model are closely tied together and
> >> their efficiency in fact often depends on this close relationship.
> >
> > What is the test for determining whether they are too tightly
> > coupled?

>

I haven't seen logical data model changes driven by anything like this in the MV world but others would know better than I. I suspect that MV does do things that would be rejected under the heading of data independence, so I'm curious what, if anything, that might be.

> > What is it that changes (the "physical model" doesn't resonate with
> > me, I want to know what software components would change) that should
> > not require a change in the logical model but does in some
> > non-relational products?

>

When I read aobut it, it makes complete sense, but then when I think about it, I don't recall any time when anything that needed to be done to the physical database ever caused me to change a logical data model (although perhaps a data source definition or hardcoded volume in days gone by).

Is there an example with something primitive like VSAM files (indexed sequential files) that would illustrate how an application would have to change the logical data model based on some physical design decision? I'm clearly missing something (lots). I don't recall ever having to make such changes.

Thanks --dawn Received on Tue Feb 14 2006 - 23:20:41 CET