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.

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

That part makes sense to me. But then he shows the ApplicationDatabase
(containing the user's data) realizing an interface, which is its schema. He
explained this saying "The way I see it, a database's schema is effectively
its interface, because that's how you access it."

Then he put a dependency from the Application to the Schema, stereotyped
with <>. His explanation: "The Application depends on the Schema
of my database, because if I change the schema, that affects my application.
The protocol is SQL."

Well, that part about the schema being the interface to the database doesn't
make much sense to me. Yet I do get his point about how the application does
have some kind of dependency on the schema.

But I'm not sure how to get this untangled. How would you express all this?

John

From:	frebe
Subject:	Re: Application, database and schema?
Date:	16 Jan 2005 10:44:34 -0800

> I like to keep the RDB/SQL knowledge very far away from the core of
my
> system.

Do you have a motivation for this?
Fredrik Bertilsson
http://butler.sourceforge.net

From:	Robert C. Martin
Subject:	Re: Application, database and schema?
Date:	Sun, 16 Jan 2005 20:31:59 -0600

On 16 Jan 2005 10:44:34 -0800, "frebe"
wrote:

>> I like to keep the RDB/SQL knowledge very far away from the core of
>my
>> system.
>
>Do you have a motivation for this?

Cleanliness.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	frebe
Subject:	Re: Application, database and schema?
Date:	16 Jan 2005 20:31:09 -0800

>>Do you have a motivation for this?

> Cleanliness.

You you have a more detailed motivation for this?
Fredrik Bertilsson
http://butler.sourceforge.net

From:	Robert C. Martin
Subject:	Re: Application, database and schema?
Date:	Mon, 17 Jan 2005 12:29:56 -0600

On 16 Jan 2005 20:31:09 -0800, "frebe"
wrote:

>>>Do you have a motivation for this?
>
>> Cleanliness.
>
>You you have a more detailed motivation for this?

Separation of concerns. I don't want the shape of my application code
to be distorted by the shape of the database engine.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	frebe
Subject:	Re: Application, database and schema?
Date:	15 Jan 2005 04:10:55 -0800

JMF wrote:
> > 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.

Do you think you will change from RDB to some other type of database?
Will your application exists longer than there will be relational
databases availible? If the answer is yes, you need to encapsulate the
use of RDB. But making an application independent of database paradigm
is not easy and it will disable you to use some of the features in an
RDB.

A much easier task is to make your application independent of RDB
vendor. Just keep to ANSI SQL.

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

SQL os a set of operations provided by the database. In a OO
programming language, an interface is a set of objects with methods. In
a non-OO programming language, an interface is a a set of functions,
procedures and variables. In a database, the interface is an access
language and a set of tables, columns and foreign keys.

An interface is something you access without knowing what is behind.

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

Why would you like to change the schema without changing the
application? Schema changes are done because you change your
information model, like adding telephone number for employees etc.
Changes like that has no meaning if the application remain the same.
The telephone number will not be used.
Fredrik Bertilsson
http://butler.sourceforge.net

From:	JMF
Subject:	Re: Application, database and schema?
Date:	Sat, 15 Jan 2005 13:06:36 GMT

"frebe" wrote in message
news:1105791055.812072.145270@f14g2000cwb.googlegroups.com...
> JMF wrote:
> > > 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.
>
> Do you think you will change from RDB to some other type of database?
> Will your application exists longer than there will be relational
> databases availible? If the answer is yes, you need to encapsulate the
> use of RDB. But making an application independent of database paradigm
> is not easy and it will disable you to use some of the features in an
> RDB.
>
> A much easier task is to make your application independent of RDB
> vendor. Just keep to ANSI SQL.

So you're saying it's okay to let the relational model show through, with
SQL to keep it vendor-independent.

> > 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.
>
> SQL os a set of operations provided by the database. In a OO
> programming language, an interface is a set of objects with methods. In
> a non-OO programming language, an interface is a a set of functions,
> procedures and variables. In a database, the interface is an access
> language and a set of tables, columns and foreign keys.
>
> An interface is something you access without knowing what is behind.

I appreciate your general definition of interface, and that the way it
manifests itself can be different in different paradigms. But, since he says
he wants to use the O-O paradigm for his entire design and is using UML to
express it, I just figured he should try to stay within it, and represent
the interface to something like his RDB in a UML sort of way. Since in the
UML an interface is a set of operations (and possibly a few variables in UML
2), that's what I would expect it to be in his model. A schema doesn't seem
to me to be a set of operations, so it doesn't seem to be appropriate to
call it an interface in the UML sense.

I like the idea of thinking of SQL as possibily representing the set of
operations, or at least the protocol for accessing the interface, though.

> > 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"
>
> Why would you like to change the schema without changing the
> application?

I don't know - I didn't say that.

> Schema changes are done because you change your
> information model, like adding telephone number for employees etc.
> Changes like that has no meaning if the application remain the same.
> The telephone number will not be used.

True, it might not change the application, but how can you know that a
priori?

John

From:	Robert C. Martin
Subject:	Re: Application, database and schema?
Date:	Sun, 16 Jan 2005 09:20:02 -0600

On Sat, 15 Jan 2005 13:06:36 GMT, "JMF" wrote:

>So you're saying it's okay to let the relational model show through, with
>SQL to keep it vendor-independent.

I like to keep the RDB/SQL knowledge very far away from the core of my
system. I push it down into utility classes on the fringe. The main
business rules and architecture of my systems make no concession to
RDBs and SQL.

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	Robert C. Martin
Subject:	Re: Application, database and schema?
Date:	Sun, 16 Jan 2005 09:18:38 -0600

On Tue, 11 Jan 2005 11:36:21 GMT, "JMF" wrote:

>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.
>
> <>
>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."
>
>That part makes sense to me. But then he shows the ApplicationDatabase
>(containing the user's data) realizing an interface, which is its schema. He
>explained this saying "The way I see it, a database's schema is effectively
>its interface, because that's how you access it."
>
>Then he put a dependency from the Application to the Schema, stereotyped
>with <>. His explanation: "The Application depends on the Schema
>of my database, because if I change the schema, that affects my application.
>The protocol is SQL."
>
>Well, that part about the schema being the interface to the database doesn't
>make much sense to me. Yet I do get his point about how the application does
>have some kind of dependency on the schema.
>
>But I'm not sure how to get this untangled. How would you express all this?

I don't think I would. The diagram above seems to convey the
concepts, but...what possible use could you put this diagram to? What
impact will it have on your code? In what way will it affect the way
you produce the software.

When you use UML for diagrams like this, there is no point in worrying
over their correctness. If they convey an idea, then you've done as
much as you can. There is no formal correctness that goes beyond
that.

You can achieve a certain amount of formal correctness when you use
UML to represent code. This only goes so far. I wouldn't depend on
UML diagrams too heavily.

See: "UML for Java Programmers" www.objectmentor.com.UMLFJP

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	JMF
Subject:	Re: Application, database and schema?
Date:	Mon, 17 Jan 2005 07:12:41 GMT

"Robert C. Martin" wrote in message
news:550lu0hfim4lqgltg7tfad31aqcsq5rhap@4ax.com...
> On Tue, 11 Jan 2005 11:36:21 GMT, "JMF" wrote:
>
> >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.
> >
> > <>
> >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."
> >
> >That part makes sense to me. But then he shows the ApplicationDatabase
> >(containing the user's data) realizing an interface, which is its schema.
He
> >explained this saying "The way I see it, a database's schema is
effectively
> >its interface, because that's how you access it."
> >
> >Then he put a dependency from the Application to the Schema, stereotyped
> >with <>. His explanation: "The Application depends on the
Schema
> >of my database, because if I change the schema, that affects my
application.
> >The protocol is SQL."
> >
> >Well, that part about the schema being the interface to the database
doesn't
> >make much sense to me. Yet I do get his point about how the application
does
> >have some kind of dependency on the schema.
> >
> >But I'm not sure how to get this untangled. How would you express all
this?
>
> I don't think I would. The diagram above seems to convey the
> concepts, but...what possible use could you put this diagram to? What
> impact will it have on your code? In what way will it affect the way
> you produce the software.
>
> When you use UML for diagrams like this, there is no point in worrying
> over their correctness. If they convey an idea, then you've done as
> much as you can. There is no formal correctness that goes beyond
> that.
>
> You can achieve a certain amount of formal correctness when you use
> UML to represent code. This only goes so far. I wouldn't depend on
> UML diagrams too heavily.
>
> See: "UML for Java Programmers" www.objectmentor.com.UMLFJP

You know, it's funny, but in spite of what I've written I happen to agree
with you. He is a very good technician, and I have great confidence in his
capabilities. Although I'm puzzled by the specific way he diagrammed things,
he explained what he was doing very well, and so even if that diagram turns
out to be right or wrong in any formal sense, I'm confident that the
software will be well produced. On the other hand, the discussion provided a
basis for coming to the useful conclusion that it might be better to try to
encapsulate the DB technology a little more, so the attempt to formalize
designs in UML can provide a vehicle for that type of discussion - I guess
you just have to know when it stops being useful.

John

From:	topmind
Subject:	Re: Application, database and schema?
Date:	22 Jan 2005 21:07:24 -0800

(* You missed the point. I was not saying that RDBs are dirty. I'm a
strong believer in "separation of concerns", and consider SQL and
business rules to be concerns that need to be separated. When
concerns aren't separated, I consider the structure to be "dirty". *)

What exactly are we separating and why? Besides, seperation is an
archaic concept in the cyber world. We have the ability to view things
together or apart as needed if we separate meaning from presentation
and if we encode them right. We can transcend the physical limitations
of Newtonian space and should if it is advantagious. However,
limitations of file systems and linear text programming languages tends
to go against this goal. I agree that sometimes we have to do such for
speed reasons, but in the longer run we should think about organization
issues instead of obsessing on making the CPU happy. Thus, "separation"
is a dying concept.

Perhaps "Isolatability" is more what you have in mind. This allows
something to be isolated for custom purposes. Thus, we may be able to
see SQL statements in the context of where they are used, or later see
them by themselves if you are changing databases or whatnot. We are not
stuck with one place OR another. Our view is whatever we want it to be,
not just what the originator thought it should be.

-T-

From:	topmind
Subject:	Re: Application, database and schema?
Date:	18 Jan 2005 00:02:11 -0800

>>> I like to keep the RDB/SQL knowledge very far away from the
>>> core of my system.

>> Do you have a motivation for this?

> Cleanliness.

"Eeeww! I touched the filthy Relational Monster.
I gotta shOOwer!"

Get real

-T-
oop.ismad.com

From:	Robert C. Martin
Subject:	Re: Application, database and schema?
Date:	Tue, 18 Jan 2005 16:33:22 -0600

On 18 Jan 2005 00:02:11 -0800, "topmind"
wrote:

>>>> I like to keep the RDB/SQL knowledge very far away from the
>>>> core of my system.
>
>>> Do you have a motivation for this?
>
>> Cleanliness.
>
>"Eeeww! I touched the filthy Relational Monster.
>I gotta shOOwer!"

You missed the point. I was not saying that RDBs are dirty. I'm a
strong believer in "separation of concerns", and consider SQL and
business rules to be concerns that need to be separated. When
concerns aren't separated, I consider the structure to be "dirty".

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo

From:	H. S. Lahman
Subject:	Re: Application, database and schema?
Date:	Thu, 13 Jan 2005 21:31:30 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).

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

>
> That part makes sense to me. But then he shows the ApplicationDatabase
> (containing the user's data) realizing an interface, which is its schema. He
> explained this saying "The way I see it, a database's schema is effectively
> its interface, because that's how you access it."
>
> Then he put a dependency from the Application to the Schema, stereotyped
> with <>. His explanation: "The Application depends on the Schema
> of my database, because if I change the schema, that affects my application.
> The protocol is SQL."

Only at the level of Systems Engineering, which is why I suspect the
diagram above is some sort of partitioning diagram. Whatever problem
the application is solving depends upon a data storage service, but
that's all. 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.

>
> Well, that part about the schema being the interface to the database doesn't
> make much sense to me. Yet I do get his point about how the application does
> have some kind of dependency on the schema.

I don't think that's what he is saying. The problem solution depends
upon a data storage service. The client-side data storage service
subsystem needs to deal with the actual storage paradigm, which includes
stuff like RDB schemas and SQL. So the implementation of the data
access service subsystem depends upon those things but it is
encapsulated within its own subsystem interface that presents a much
more generic, problem-specific interface to the rest of the application
(i.e., however many subsystems compose the problem solution).

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

From:	JMF
Subject:	Re: Application, database and schema?
Date:	Sat, 15 Jan 2005 08:53:51 GMT

----- Original Message -----
From: "H. S. Lahman"
Newsgroups: comp.object
Sent: Thursday, January 13, 2005 10:31 PM
Subject: Re: Application, database and schema?

> Responding to JMF...

First of all, thanks for taking the time for this.

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

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

>
> >
> > That part makes sense to me. But then he shows the ApplicationDatabase
> > (containing the user's data) realizing an interface, which is its
schema. He
> > explained this saying "The way I see it, a database's schema is
effectively
> > its interface, because that's how you access it."
> >
> > Then he put a dependency from the Application to the Schema, stereotyped
> > with <>. His explanation: "The Application depends on the
Schema
> > of my database, because if I change the schema, that affects my
application.
> > The protocol is SQL."
>
> Only at the level of Systems Engineering, which is why I suspect the
> diagram above is some sort of partitioning diagram.

Hmm, I don't think he meant it as that.

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

> >
> > Well, that part about the schema being the interface to the database
doesn't
> > make much sense to me. Yet I do get his point about how the application
does
> > have some kind of dependency on the schema.
>
> I don't think that's what he is saying. The problem solution depends
> upon a data storage service. The client-side data storage service
> subsystem needs to deal with the actual storage paradigm, which includes
> stuff like RDB schemas and SQL. So the implementation of the data
> access service subsystem depends upon those things but it is
> encapsulated within its own subsystem interface that presents a much
> more generic, problem-specific interface to the rest of the application
> (i.e., however many subsystems compose the problem solution).

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.

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.

Thanks again for your comments,

John

From:	H. S. Lahman
Subject:	Re: Application, database and schema?
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.
>>>
>>> <>
>>>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

From:	JMF
Subject:	Re: Application, database and schema?
Date:	Mon, 17 Jan 2005 07:04:24 GMT

"H. S. Lahman" 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.
> >>>
> >>> <>
> >>>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

From:	frebe
Subject:	Re: Application, database and schema?
Date:	15 Jan 2005 07:31:45 -0800

> So you're saying it's okay to let the relational model show through,
with
> SQL to keep it vendor-independent.

The relational model is widely used and has proved to work in many
different areas. And there are a lot of vendors supporting the SQL
standard. The risk you take by tie you self up to the relational model
is very small. Today software customers ask for two things:
Independence of operative system and database vendor. Independence of
database paradigm is not a customer request at all.

> But, since he says he wants to use the O-O paradigm for his entire
design and is
> using UML to express it.

The problem is that the O-O paradigm is not an universal tool to model
everything in a computer system. UML is not a tool for modelling
information. It is a tool for modelling software. But if the
application interacts with a relational database, the database
interface (tables, etc) can easily be modeled as classes and methods,
like you showed in your original posting. Anyway, when you design the
information (schema) you should use a schema design tool, and not UML.

> Since in the UML an interface is a set of operations (and possibly a
few variables in > UML 2), that's what I would expect it to be in his
model
I use to generate classes for every table in my schema. If we have a
table called customer the generated classes would look like this:
CustomerTable
getCustomerNoColumn()
getNameColumn()

CustomerRecord
getCustomerNo()
setCustomerNo(int no)
getName()
setName(String name)

This is the applications interface to the database. A database schema
can very well be expressed in a OO notation.

>> Schema changes are done because you change your
>> information model, like adding telephone number for employees etc.
>> Changes like that has no meaning if the application remain the same.
>> The telephone number will not be used.
> True, it might not change the application, but how can you know that
a
> priori?
I said that a schema change ALWAYS changes the application. Othwise it
would be pointless.
Fredrik Bertilsson
http://butler.sourceforge.net

From:	JMF
Subject:	Re: Application, database and schema?
Date:	Mon, 17 Jan 2005 07:20:30 GMT

"frebe" wrote in message
news:1105803105.499266.197720@c13g2000cwb.googlegroups.com...
> > So you're saying it's okay to let the relational model show through,
> with
> > SQL to keep it vendor-independent.
>
> The relational model is widely used and has proved to work in many
> different areas. And there are a lot of vendors supporting the SQL
> standard. The risk you take by tie you self up to the relational model
> is very small. Today software customers ask for two things:
> Independence of operative system and database vendor. Independence of
> database paradigm is not a customer request at all.
>
> > But, since he says he wants to use the O-O paradigm for his entire
> design and is
> > using UML to express it.
>
> The problem is that the O-O paradigm is not an universal tool to model
> everything in a computer system. UML is not a tool for modelling
> information. It is a tool for modelling software. But if the
> application interacts with a relational database, the database
> interface (tables, etc) can easily be modeled as classes and methods,
> like you showed in your original posting. Anyway, when you design the
> information (schema) you should use a schema design tool, and not UML.
>
> > Since in the UML an interface is a set of operations (and possibly a
> few variables in > UML 2), that's what I would expect it to be in his
> model
> I use to generate classes for every table in my schema. If we have a
> table called customer the generated classes would look like this:
> CustomerTable
> getCustomerNoColumn()
> getNameColumn()
>
> CustomerRecord
> getCustomerNo()
> setCustomerNo(int no)
> getName()
> setName(String name)
>
> This is the applications interface to the database. A database schema
> can very well be expressed in a OO notation.

OK, thanks.

> >> Schema changes are done because you change your
> >> information model, like adding telephone number for employees etc.
> >> Changes like that has no meaning if the application remain the same.
> >> The telephone number will not be used.
> > True, it might not change the application, but how can you know that
> a
> > priori?
> I said that a schema change ALWAYS changes the application. Othwise it
> would be pointless.

Ah, okay, in that case it was just a misunderstanding - we're in agreement
on that point.

John

From:	frebe
Subject:	Re: Application, database and schema?
Date:	18 Jan 2005 01:23:39 -0800

> I don't want the shape of my application code
> to be distorted by the shape of the database engine.

Unless it is a OO database.....
Fredrik Bertilsson
http://butler.sourceforge.net

From:	Shayne Wissler
Subject:	Re: Application, database and schema?
Date:	Tue, 18 Jan 2005 09:09:35 -0700

"frebe" wrote in message
news:1106040219.531365.106920@f14g2000cwb.googlegroups.com...
>> I don't want the shape of my application code
>> to be distorted by the shape of the database engine.
>
> Unless it is a OO database.....

Evidently you miss the point of an OO database... Anyways, RCM said that he
usually didn't use them, so you definitely missed RCM's point.

Shayne Wissler
http://www.thoughtsonsoftware.com

From:	Robert C. Martin
Subject:	Re: Application, database and schema?
Date:	Tue, 18 Jan 2005 16:30:42 -0600

On 18 Jan 2005 01:23:39 -0800, "frebe"
wrote:

>> I don't want the shape of my application code
>> to be distorted by the shape of the database engine.
>
>Unless it is a OO database.....

Unfortunately my experience with OO databases is that they aren't
seamless. Those times that I have used them, I've put a layer between
them and the application. (sigh).

-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo