Re: Application, database and schema?

From: JMF (jfavaro_at_tin.it)
Date: 01/17/05 

Date: Mon, 17 Jan 2005 07:04:24 GMT

"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:EtfGd.2718$hC2.1178@trndny04...
> 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.

Yes, that's right, it's a hardware control system.

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

Makes sense. I'll convey that message to him.

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

Great, that sorts out the subsystem partitioning well for me.

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

Yes, I also suspect that the SQL view is coloring the way he's doing the
diagram.

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

Thanks, this is very helpful.

John

Relevant Pages

  • Re: Newbie Modelling Interface Question
    ... A client's access to this subsystem is ... interface has a message identifier and a by-value data packet. ... The client then has a pointer to each interface. ... For example, in a hardware interface, clients usually want to manipulate ...
    (comp.object)
  • Re: Application, database and schema?
    ... > application of an RDB. ... Specific data storage paradigms like RDB schemas and SQL ... Hardware Interface: This subsystem understands how to talk to the ...
    (comp.object)
  • Re: Restricting functionality on objects: "remote access proxy" (pattern)
    ... about the current user's access rights in a chat. ... If the level of privilege can change during the chat, then whoever understands that change context can simply reset the privilege attribute value. ... The simplest implementation is for the subsystem interface to re-dispatch those messages to objects that have the responsibilities needed to to service the user's request. ...
    (comp.object)
  • Re: What doesnt lend itself to OO?
    ... The whole idea that a subsystem is just ... > If the clock service has identity then the client looks like... ... The first line exists in the server. ... external interface is the traditional input interface whose ...
    (comp.object)
  • Re: Help on choosing a valid pattern: composite or not?
    ... But that class would only exist in the UI subsystem in my ... In the GUI subsystem where GfxNode might live I am expressing an entirely different set of paradigms for display and I might have a handy MVC infrastructure to make the code simpler, which is where GfxNode comes into the picture. ... I can go directly to the View from the subsystem interface. ... Let's say I have defined a Facade pattern class for the interface called, for lack of anything better, GUIInterface. ...
    (comp.object)