| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
Home -> Community -> Usenet -> comp.databases.theory -> Re: Reminder, blatant ad
michael_at_preece.net wrote:
[..]
> You can do what you like with Pick.
I rest my case - the rest is a mere bagatelle!
Cheers, Frank.
> 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
![]() |
![]() |