Re: Application, database and schema?

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/15/05 

Date: Sat, 15 Jan 2005 20:58:12 GMT

Responding to JMF...

>>Caveat: I assume below this application solves soem significant problem
>>for the customer (as opposed to being a CRUD/USER pipeline between the
>>RDB and the UI).
>
>
> I'm not exactly sure what you mean by that (because I'm no expert in this
> are), but here's the application: it's a kind of monitoring system, where
> there's also a requirement for a type of "black box," like they have on
> airplanes. So the log of events has to be kept somewhere and stored away, so
> that if something happens, they can take a look at that log. They've decided
> that it made sense simply to keep that log of events in a simple relational
> database. So it's not a big deal, a very straightforward (and not large)
> application of an RDB.

CRUD = Create, Retrieve, Update, Delete
USER = Update, Sort, Extract, Report

This used to be the way large segments of IT worked. The application
really did nothing more that convert between the UI and DB views of the
data.

Your app sounds more like a hardware control system, in which case the
classic CRUD/USER layered models won't work because your UI is really a
hardware interface for the monitoring.

>
>
>>>While we're sort of on the topic of O-O and databases: a colleague has been
>>>drawing a class diagram for a system where there's also an RDB (I think it's
>>>MySQL) that does something simple like store the log, the list of events.
>>>But the way he depicted this situation I found puzzling.
>>>
>>> <<protocol>>
>>>Application-----------> Schema
>>> | / \
>>> | ___
>>> | |
>>> V |
>>> MySQL ---------->ApplicationDatabase
>>>
>>>Since that probably doesn't print well, here's how he described it: "The
>>>application has an association with the MySQL RDB. It in turn has an
>>>association to the actual database containing the data."
>>
>>What is this diagram supposed to represent? A block diagram (UML
>>Package Diagram) of the overall application partitioning? Or a Class
>>Diagram for some specific functionality?
>
>
> It's just part of his Class Diagram for the overall system, where in this
> part he's showing where the RDB comes in. He's simply trying to say "My
> application is using an RDB to manage the database containing the log of
> events." So those are classes for him.

Then I don't like the diagram at all. As described the
ApplicationDatabase isn't even part of the application; the RDB will
have its own engine. But my real objection is the failure to separate
concerns.

>>Whatever problem
>>the application is solving depends upon a data storage service, but
>>that's all.
>
>
> Right, that's exactly it; as I mentioned above, the problem the application
> is solving is "monitor the safety-related equipment," and the data storage
> service is used to store the event log.
>
>
>>The problem solution should be completely indifferent to
>>whether the data is stored in an RDB, an OODB, flat files, or clay
>>tablets. Specific data storage paradigms like RDB schemas and SQL
>>should be hidden from the problem solution.
>
>
> That's a very good point, that he did not respect, in the sense that he went
> straight to representing the RDB/SQL stuff at the same level as the other
> classes. There's no level of abstraction (at least that I've found) where he
> hides the DB technology.

On the application side one really has three distinct subject matters
that warrant encapsulation in subsystems:

Hardware Interface: This subsystem understands how to talk to the
hardware that is being monitored. It understands stuff like split
registers and bit scaling. I would expect it to be implemented with
classes in it like Instrument, Register, Field, etc.

Data Access: This subsystem understands the persistence paradigm, in
this case an RDB with a SQL interface. So it would map data into the
RDB paradigm via classes like Schema, Table, Tuple, and Field.

[As a practical matter, if one is using a SQL interface and the data to
store isn't very complicated, one might not even have to implement the
subsystem. One might be able to construct the SQL strings and dispatch
them in a subsystem interface that was a essentially GoF Facade pattern
without any classes to talk to. It would just need an internal table
lookup for field names, etc. to insert in the SQL strings.]

Monitoring Logic: This subsystem understands the monitoring problem
(e.g., when to poll the instruments and how to interpret the hardware
values). It talks to both Hardware Interface and Data Access. The
classes here would be whatever is appropriate for that subject matter in
your particular context.

> It sounds like what you're saying there is that a partitioning should occur
> at some point where the data access subsystem presents an interface to the
> rest of the application that shows no indication of the technology inside;
> whereas within the subsystem for data access, there will necessarily be
> implementation dependencies with things like SQL/schema dependencies. So I
> can certainly tell him to create that partitioning and better encapsulate
> the database technology.

Yes, basically:

               [Monitoring Logic]
                  | |
                  | |
                  V V
   [Hardware Interface] [Data Access]

In terms of a UML Package Diagram each [...] would be a Subsystem. The
dependency arrows indicate a client/service relationship. (However,
that does not mean the communications are mono-directional;
communications can be initiated in either client or service.) Each
would have its own interface.

The interface to the [Data Access] subsystem would be independent of the
  storage mechanism, typically a pure bivalve data transfer interface
based upon {message ID, data packet} where each side encodes/decodes the
data packet for its context based upon the "message ID". So the input
interface to [Data Access] might have a method like:

storePressure (instrument ID, value);

or, in an event-based interface the event might be:

{PressureEvent, {instrument ID, value}}

>
> I still think it's weird for him to think that "the schema of a database is
> its interface." For me, an interface is the set of operations provided by
> something. If he was just trying to express the idea that "if the schema
> changes, then the application that accesses the database has to know it"
> then instead of talking about schemas as interfaces, it would have sufficed
> to say there was a dependency on the schema and that's it.

I suspect he is biased by the SQL view of access. SQL itself is an
interface language and to use it one must explicitly identity schema
elements.

As I noted above, if things are simple enough the subsystem can devolve
to a single Facade class by using SQL. Nonetheless the table/field
identity strings needed for SQL should be hidden within that class'
implementation. That allows one to isolate any data storage changes to
that single class' implementation.

*************
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
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Relevant Pages

  • Re: data structure complexity vs. application maintenance cost
    ... that subsystem is based on the problem solution's needs for data and the ... In such situations the view of the data is quite likely to be different than the generic RDB schema view. ... Every paradigm switch caused great gnashing of teeth because application solutions were inextricably married to a particular paradigm. ... It would be even more naive to believe that SQL will remain the primary interface to RDBs or even that SQL drivers were truly portable. ...
    (comp.object)
  • Re: Application, database and schema?
    ... > hardware interface for the monitoring. ... This subsystem understands how to talk to the ... > this case an RDB with a SQL interface. ...
    (comp.object)
  • Re: No knowledge of the database?
    ... can answer Yes because neither system used an RDB; ... any dependence on it persistence being through an RDB. ... would have a subsystem where knowledge of RDBs would be ... interface subsystem one has classes like Window and Control. ...
    (comp.object)
  • Re: Encapsulation vs separation of concerns
    ... > I agree that the subsystem would have to be rewritten. ... This is not true for SQL Provider? ... If a new storage system comes along chances are the ... How likely is it really that one would move from an RDB ...
    (comp.object)
  • Re: Encapsulation vs separation of concerns
    ... I agree that the subsystem would have to be rewritten. ... accessing the same storage paradigm. ... This would be a poor subsystem interface because it exposes objects the ... hierarchical, direct access, RDB, OODB, and custom) so in the worst case ...
    (comp.object)