Re: Relational model versus object model

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 02/23/04 

Date: Mon, 23 Feb 2004 22:33:28 GMT

Responding to Jacobs...

>>As far as concurrency is concerned, the DBMS is the logical place to
>>address that when there are multiple readers and writers of data. A
>>particular application should not have to worry about what other
>>applications are reading and writing the data. OTOH, the application
>>may have its own set of concurrency problems that the DBMS has no
>>business knowing about.
>
>
> Examples would be helpful. Note that I am a proponent of
> a "local" DBMS engine for stuff that does not belong in
> the "formal" or "central" DBMS.

I assume you mean examples of local concurrency. Your application is
inventory control for a retail bricks & mortar business. It receives a
message whenever a bar code is read at a register. Each reading
initiates a thread. In a typical IC system that processing can be
trivial (e.g., updating the DB) for some items and very complex (e.g.,
forecasting, triggering orders, triggering warehouse deliveries, etc.)
for others. For a big business one could be simultaneously processing
10K reads at any given time.

>>>>>* Multi-language and multi-application data sharing
>>>>
>>>>I didn't include this one because I don't know what it means. Sounds
>>>>good, though.
>>>
>>>
>>>Sharing information with multiple languages and applications
>>>in a convenient, consistent way.
>>
>>NS,DT! That's exactly why we separate reading and writing data from
>>business problem solutions. That portability is achieved by decoupling
>>the DBMS from the specific business problems being solved. If the DBMS
>>is decoupled from the problem solutions, it is also decoupled from the
>>solution mechanisms.
>
>
> Again you appear to be assuming that only persistence is being
> considered.

On the DB-side, Yes. If one doesn't do that and allows the DBMS to get
hung up on business rules and policies, the data is no longer decoupled
from its use. It's fundamental complexity management: divide and
conquer by separating concerns.

>
> I'll tell you what. I would like to see an OO API that does
> all the above, and this includes inter-language info sharing.

I have no idea what you are asking for. The decoupling occurs because
all the DB holds is data. Data is already independent of application
language or problem solutions. It only has storage semantics. The
interpretation and use is all on the client side.

To put it another way, the relational data model's popularity exists
because it allows one to describe just the intrinsic properties of data
without the pollution of problem solution specializations. The
Phoenicians did the same thing, albeit much less precisely, with
cuneiform and clay tablets.

>
> Most likely satisfying this request will result in the invention
> of a database of some sort (or at least an interface to one).
>
>
>>>>>Caching allows a lot of RDBMS work to be done in RAM.
>>>>
>>>>That isn't the problem. It's the searches and key comparisons required
>>>>when identity and relationships are tied to embedded data values.
>>>>That's fine for data management or even CRUD/USER pipeline applications
>>>>but one doesn't want to solve complex business problems that way.
>>>
>>>
>>>Please define/clarify "complex business problems".
>>
>>Problems where the Business layer processing is large compared to either
>>the Presentation (UI) or the Data layers in a conventional layered
>>model. IOW, applications that are not simple USER/CRUD pipelines
>>between UI and DB.
>
>
> For one, you seem to assume that CRUD applications are always
> simple. If they were, they would be factored into an
> off-the-shelf-box. (There are RAD tools that claim to do such,
> but they rarely offer or facilitate the
> long-term customization that many
> businesses want.) But I will agree that business applications tend to
> be "link bound" as opposed to "node-bound". This means that
> the hardest part of "processing" is gathering information
> for many peices and sources of data. In other words, the
> gathering is usually the complexity bottleneck rather than the
> raw processing.

USER/CRUD is simple by definition. Whichever acronym one uses the
operations are trivial and very similar but they are performed on
mountains of data. One is essentially just reformatting the data.
However, that reformatting is usually highly constrained, which is why
rear end query languages like SQL evolved; they captured the invariants
of accessing data stored using the relational data model. That reduces
the level of tedium in collecting data by raising the level of
abstraction of access.

>
> But if you have a specific example where relational tends
> to choke or be complicated compared to OO, I would like to
> inspect it. I am sure there are a few such cases because
> nothing is good at everything. However, for the vast
> majority of business applications, procedural/relational
> is superior IMO. At least not objectively worse.

Where did I say that the relational model "chokes" for data storage? It
is an excellent paradigm for that, which is why one doesn't see a lot of
CODASYL anymore.

However, client side applications (or at least a largish subset of them)
aren't simply about USER/CRUD processing of large volumes for data.
They do complex manipulations of the data and for that one needs better
paradigms that are oriented around behavior as well as data. The
relational model sees the world solely in terms of static data but
problem solutions are inherently dynamic.

>>>Context-specific is often not "long-term". Besides, one can
>>>reformat stuff as needed in a given module without all the
>>>syntactical overhead and "setup work" involved in OO.
>>>For example, split it up and put it into an associative
>>>array that a particular task needs.
>>
>>Actually being context-specific is crucial to large scale reuse.
>>Focusing on abstracting the invariants of a specific subject matter and
>>encapsulating them properly behind interfaces is an excellent way to
>>provide long-term stability and isolate changes.
>
>
> That is what a schema is: an interface. Data-centric interfaces
> are just as useful as behavior-centric interfaces. Plus, they
> make inter-language communication easier than behavior-bound
> approaches.

However, you said it yourself: it is a data centric interface. That's
fine for data storage but it doesn't cut it for <nontrivial> data
processing.

BTW, I disagree that interface is a good analogue for schema. A schema
defines a model of data entities. It defines what those entities are.
An interface defines access to entities. So SQL is an interface for
accessing data defined by a schema.

>
>
>>Maintaining a narrow
>>focus facilitates recognizing invariants. That's why we have GUI
>>builders, web builders, and RAD IDEs; they each abstract invariants of a
>>very narrowly defined subject matter. In fact, note that SQL is an
>>example of abstracting the invariants of accessing RDB persistence.
>
>
> There you go again: "persistence".
>
> But you are heading in the right direction in that databases came from
> the packaging of *commonalities* of data-handling into a
> language-neutral standard (more or less), IOW "abstraction". OO apps
> tend to want to reinvent all that from scratch for each and every app.

I already pointed out in this thread somewhere that the RDB view and the
OO view are peer views of the same underlying problem space. They are
mappable to one another but they are not derived from one another.
Similarly, functional programming, expert systems, and other software
solution paradigms also present peer views of the same problem spaces.
One picks the right view to solve the problem in hand.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH

Relevant Pages