Re: No knowledge of the database?

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/03/04 

Date: Fri, 02 Jan 2004 23:16:10 GMT

Responding to Bertilsson...

> When I look at different forums about object oriented programming I
> often finds statements like this:
> "I see databases as a commodity that should be swappable."
> "...such that developers (computer programmers) can write
> object-oriented applications using those object classes without any
> explicit reference to or knowledge of the underlying database or its
> structure."
>
> I have worked with many information systems (production control,
> logistics, human resouce etc) with java and VB as programming
> languages. But in all cases a good knowledge of the (relational)
> database structure is absolutely necessary for every programmer (even
> client programmers). Are there anybody here on this forum that develop
> information systems and don't know about the database structure? If
> yes, how do you do if you have a system failure due to wrong data, and
> the data in the database has to be corrected. Do you call someone else
> that knows about the database structure?

The answer to your first question is Yes. I was, among other things,
lead on both General Ledger and Inventory Control at a Fortune 500. I
can answer Yes because neither system used an RDB; both were ISAM-based
(it was in the early '70s). B-) But that is pretty much the point; the
subject matters were invariant with the way data was stored. Double
entry bookkeeping doesn't change if one stores the data in flat files,
ISAM, RDBs, OODBs, or clay tablets.

Now I know a whole lot more about RDBs but I don't work in IT anymore.
However, if I did go back to IT, I would build the application without
any dependence on it persistence being through an RDB. The application,
though, would have a subsystem where knowledge of RDBs would be
essential. That subsystem would act as an interface between the RDB and
the problem solution.

The point is that there are multiple subject matters in nontrivial
applications. Bookkeeping, forecasting, UI, and persistence are all
very different subject matters with very different paradigms. One needs
to bring to the table the appropriate domain knowledge for the subject
matter. Persistence is simply not relevant to double entry bookkeeping,
allocations, P&Ls, and Balance sheets. Similarly, the semantics of
T-Accounts, debits, and credits are of no concern to persistence.

So we decouple the subsystems through "firewall" subsystem interfaces
that allows us to abstract the same underlying problem space entities in
quite different ways capturing quite different problem space invariants.
  So in the persistence access subsystem one has objects like Table,
Schema, Tuple, and Attribute. In the bookkeeping subject matter one has
objects like T-Account, P&L, SummaryAccount, and Allocation. In a GUI
interface subsystem one has classes like Window and Control. When
working on a particular subject matter, one views the problem
exclusively from that perspective. But they all abstract, in some
fashion, the same underlying problem space entities and the interfaces
provide the mapping between those quite different views.

The golden Rule is: Solve the business problem first and then worry
about how data is stored and how one talks to the user. In doing so,
let the business problem drive the interface design. That is, provide
subsystem interfaces to UI and persistence that are tailored to the
problem's needs. Then let the relevant access subsystem provide the
mapping between those needs and the RDB schema and resources.

>
> My second question is: Are there anybody on this forum that have
> experience from changing the database structure without major changes
> in the source code, not just the data access layer? If yes, I would
> really know how to do?

Again, Yes, but only indirectly in IT. We needed to upgrade the IC
system to an RDB. However, when tried to estimate out how much effort
it would require it became clear it would be cheaper to build a new one
from scratch. That's because the original system did NOT separate the
IC problem from the persistence problem. So the ISAM structure
permeated the code and made it almost impossible to convert.

[Not quite true, there were tools to convert ISAM to RDB. However, it
was much like reverse engineering to OO models -- all you got out was a
garbage RDB schema. To get a good RDB schema required manual conversion
and major surgery.]

I have converted the persistence mechanism in the R-T/E world a couple
of times. However, when we did that it was done right. The application
(a 1 MLOC device driver) was independent of the persistence by design so
all we had to replace was one subsystem (about 10 KLOC).

I would also point out that I have watched UIs move from punched cards
to command line to 80x24 character terminals to GUIs to web browsers.
That's a very similar situation where the problem solution should be
independent of how one talks to the user. It was always tremendously
painful until the application solution was separated from the user
access subject matter. Once that was done, it was a relative piece of cake.

In either case, the key is to isolate the access in a subsystem that is
encapsulated behind an interface. That should insulate the basic
problem solution from the access mechanisms. At worst one just has to
throw away a single subsystem. At best, one can accommodate substantial
change with relatively minor changes within the subsystem. That's
because the subsystem will encode the invariants of the subject matter
while leaving detailed differences to data values.

That, in turn, allows one to do things like schema changes without
touching the code. One can read the RDB itself to object the schema and
that allows one to employ a Factory to instantiate the RDB view. The
one only needs lookup tables to map identity across the subsystem
boundary, which can also be defined in external data.

*************
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

Quantcast