Re: Mixing OO and DB

From: Patrick May <pjm_at_spe.com>
Date: Wed, 19 Mar 2008 17:31:44 -0400
Message-ID: <m2abkubdtr.fsf_at_spe.com>

frebe <frebe73_at_gmail.com> writes:
> On 16 Mar, 18:20, Patrick May <p..._at_spe.com> wrote:
>> "Brian Selzer" <br..._at_selzer-software.com> writes:
>> > "Patrick May" <p..._at_spe.com> wrote in messagenews:m2wso9i9be.fsf_at_spe.com...>> > I'll
>> > buy that a schema can be part of multiple applications, but that
>> > there can be multiple ways to represent the same information does
>> > not alter what information is to be and can be recorded.
>>
>> We seem to be in agreement that different specific schemas can
>> provide access to the same underlying information. That suggests
>> that your statement that ". . . the schema is an integral part of
>> the application specification, and it cannot be decoupled . . ."
>> needs clarification. Would you agree with the formulation "The
>> logical schema is an integral part of the application
>> specification."? By "logical schema" I mean the implementation
>> independent set of data that supports the application.
>
> The logical schema is the relations (base relations - tables, and
> derived relations - views). But the fact whether the relations is a
> table or view, is not part of the logical schema. That is a physical
> detail.

     That's fine, but splitting hairs from the application implementation point of view. The application implementation sees a particular schema specification (tables, views, or some combination).

>> If you agree with this, the second half of your claim
>> ". . . and it cannot be decoupled" is clearly incorrect because the
>> application implementation deals with the physical schema.
>
> Wrong. The applications deals with the logical schema. It has no
> idea if it is accessing a table or a view.

     There are multiple possible sets of tables and views that can provide the same information. Therefore Mr. Selzer's claim that the application implementation and the specific schema it uses cannot be decoupled is incorrect. The specific schema is not "integral" to the application implementation.

>> Since you agree that multiple different physical schemas are
>> possible, decoupling the application from any particular set of
>> those is both possible and good design.
>
> Multiple logical schemas are also possible. The decoupling is done
> using views.

     That's one way. Non-relational languages provide others.

> I thought that Brians examples with coordinates was pretty obvious,
> but maybe some futher clarification is needed. Suppose you have a
> table for Cartesian coordinates. Now you have an application that
> needs to work with polar coordinates instead. The solution is to
> create an updateable view for polar coordinates, which derives the
> data from the original table. Another solution could be to create a
> new table using polar coordinates and creating a view (with the same
> name as the original table) providing the Caresian coordinates. The
> logical schema will now contain two relations for the same data in
> different format.

     Alternatively, the data could be loaded into an object that does the conversion on demand. The rest of the application wouldn't need to know about the database or the specific schema at all.

>> Further, the view that the schema is integral to the
>> application is very data centric. Different applications may need
>> the data in different forms, not all of which are relational.
>
> On the logical level, virtually any data can be represented in a
> relational form.

     On the logical level, all Turing complete languages are equally powerful. For particular applications, some are far more expressive and usable than others. Similarly, the relational model is not always the most expressive for a particular application.

>> There is therefore a need to translate between the data structures,
>> which is another good reason to decouple the application from the
>> specific physical schema being used.
>
> Since the application is not dealing with the physical schema, it is
> not able to do that translations. It is already done in the RDBMS.

     That is not correct. The application deals with a specific schema with data represented in the relational model. That is not always the format required by the application.

Sincerely,

Patrick

---

S P Engineering, Inc. | Large scale, mission-critical, distributed OO

                       | systems design and implementation.
          pjm_at_spe.com  | (C++, Java, Common Lisp, Jini, middleware, SOA)

Received on Wed Mar 19 2008 - 22:31:44 CET