[PYTHON DB-SIG] Objects and Relational Databases - Part 2

Joel Shprentz shprentz@bdm.com
Wed, 10 Jan 1996 14:23:32 -0500

This and the previous message are forwarded from the Coad Letter mailing
list, which is sent monthly from Object International.  In these two
messages, Peter Coad discusses how problem domain objects should interact
with data management objects.  The discussion extends the data management
appendix to Coad's object modelling book, which was published last year.

Joel Shprentz              (202) 863-3121
BDM Federal, Inc.          shprentz@bdm.com
1501 BDM Way
McLean, VA 22102
------------------------- Forwarded Message Follows --------------------------
Return-Path: <owner-coad-letter@oi.com>
From: <owner-coad-letter@oi.com>
Date: Tue, 9 Jan 96 14:07:06 CST
To: coad-letter@oi.com
Subject: 23b--Data Management--"Objects and RDB" Q&A (Part 2)
Sender: owner-coad-letter@oi.com
Reply-To: owner-coad-letter@oi.com

The Coad Letter
Issue 23b
Category: Data Management
Title: "Objects and RDB" Q&A (Part 2)
Date: Tuesday, January 9, 1996

Continuing from Part I --

                        "Objects and RDB:
        App Architecture and Other Practical Considerations"

                    Peter Coad and David North
              (with added insights from Ken Ritchie)
                           January 1996

Q. Do you simply add attributes and services that came from a DM point-of-
   view to PD objects.

   For example:
   - Added id's and services that are only used internally
   - Added correlation objects
   - Taking a problem-domain attribute and breaking it up into fields
   - Taking a problem-domain attribute and adding a new class.

A. [Peter] The model changes, it's true. And PD objects are affected
   by this. This is why view management is so very important.

   Responses for each example:
   - Added id's and services that are only used internally
     -- Hide these with view management.
   - Added correlation objects
     -- These are a problem. What I've done is let domain experts
        know I need them for relating objects in one class to another.
   - Taking a problem-domain attribute and breaking it up into fields
     -- Here, you are simply choosing to show more detail about
        the attributes in an object model. And that is just fine
        (not a big deal).
   - Taking a problem-domain attribute and adding a new class
     -- An improvement to the object model; might even be added
        insight that comes from building part of the app; and
        that's just fine.

   [David] Agreed. No need ending up with two models (both an object
   model and a data model); use an object model all the way.

Q. About the DMserver object. What are its services? It seems like
   they are:
   - Find a specific DM object.
   - Maintain a changes log.
   - Save all.

   Does a significant difference arise if one chooses to
   make each DM object global, rather than have a DM
   server watch over them?

   An HI object could tell each DM object to save itself,
   couldn't it?

A. [David] The DMserver keeps the change log in the automated version
   of DM.

   Not much change if all of the DMobjects are global. Just more
   global variables; I prefer to have fewer.

   If you are keeping a change log of all of the objects that are
   changed, then the HI might send the saveAll to the DMserver to save
   all of the changed objects.

Q. Would a DMserver object have some other services?

A. [David] Yes: connect/disconnect to database(s).

Q. The "change log" attribute in the DM Server object.
   What is it?

A. [Peter] It is a collection of objects that have changed.

  [David] Includes deletions -- plus additions and deletions to
  collections, too.

Q. If it is a collection of objects, how does the DMserver
   work with them. Does it tell each changed PD object to save
   itself? Or?

A. [David] Yes, the DMserver asks each to save -- and then each
   PD object asks its DM object to "save me."

Q. Should the change log be held by the DMserver -- or by each
   DM object (each responsible for the objects within a specific
   PD class)?

A. [David] It could, but then a saveAll would have to ask each
   DMobject if it had any changes -- instead of just knowing which
   ones need to be saved. Order of the changes can be important
   (integrity constraints in the DB) and this can be preserved
   in a single change log.

Q. Could you show us an example of a real DM object, how it is really
   done (Smalltalk would be fine)? Really, we are looking for a
   pseudo-code example of how a real DM object does its job --
   including database interaction.

A. [David] The ones that we have are like the automated version
   I discussed. Because they provide generic support for any object,
   they are very complicated. If I can work it in, I will build a
   simple one and send it to you, for you to look at.

Q. How many objects does one bring into memory at one time?
   A challenging question. Yet is there some way of deciding
   how many should be brought in at one time?

A. [Peter] That is an age-old question, when working with RDB.
   One heuristic: use problem-domain groupings.

   [David] Agreed. Usually it is one at a time or a group to support a 

Q. If an RDB cursor can be used in this way, can you provide
   an example?

A. [David]  Use the cursor when you want to bring in a
   collection of objects (loadAll, loadEmpForDept)
      1) special service in the DM for this
      2) issue the SQL request
      3) process each row returned by the cursor and convert it
         to an object -- and add that object to the collection
         to be returned.

Q. PersistentPD class?
      Is there a PD class, too?
      Are all PD classes persistent? (If not, please give examples.)

A. [Peter] A PD class? Usually, no.

   Classes with no attributes (e.g., classes added to encapsulate
   behavior across a collection, with just one object in a class)
   do not need to be persistent; the solo objects are simply created
   and initialized at startup each time.

   [David]  The PersistentPD class is the generalization class
   for any PD class that needs persistence.

   [David]  Most of the time in business applications, all of the
   PD classes are persistent. There are cases (as Peter mentioned)
   in which PD classes are not persistent. I'd add these
   special cases to the list: special window or report structures
   (often just containers of persistent objects).

Q. Triggers?
   If the database uses triggers to support its consistency,
   how does that relate to content in the PD component?

   For example, if super-org is deleted, then its sub-orgs are
   deleted. Who does this? And how is it shown in an object model?

A. [David] If you want the database to automatically do the work
   by triggers, then the only place to describe that work is in
   the service description or comments in the object model. The
   example you mentioned, the delete for super-org, does all
   the work of deleting all of the sub-orgs; only in the delete
   service description would that work be described. You need
   to be a bit careful about this, because what if you had sub-org
   objects in memory, yet they end up getting deleted in the
   database without getting removed from memory?

   Again, keeping the object model in your development means that you
   may not always make use of all of the capabilities of the RDB.

Q. If you are building a client-server system, where do you allocate
   the objects? Some possibilities:
   - some PD on each
   - HI to client; DM to server
   - DM on client, sending SQL to server

A. [Peter] HI-PD-DM on the client and the RDB on the server.
   SQL is passed over the LAN.

   [David] Agreed.

Q. Can you recommend a product that supports network messaging --
   using objects (e.g., an object request broker of some sort).
   Any experience with this?

A. [Peter] Mark Mayfield is working on a banking app that
   is doing development in this area.

   [David]  We are looking at HP-Distributed Objects using
   VisualWorks, but we don't have much experience with it yet.
   Some of the ODB vendors also have support for this.

Q. HI-PD-DM is much like the three-tiered model.
   Yet is this the same three-tiered system architecture model?

A. [Peter] Good point. HI-PD-DM is a software architecture.

   The three-tiered model is most often used in the context of
   system architecture.

   These two are related (both a triad; both a separation of
   concerns), yet the mapping is not necessarily 1:1.

   [David] Conceptually they both come from the desire to separate
   the responsibilities. Usually today the three-tiered model is
   talking about the number of machines in the system architecture
   and the responsibilities of the machines.

Q. RDBs each have their strengths. The available services vary,
   product to product.

   How many of those services should one try to use?
   Use it to get the most out of the database?
   Or limit use to what fits well with the PD objects?
   What should one think of in making such decisions?

A. [David] The answers to all of these questions are based on
   application-specific tradeoffs. No strategies on this, just yet.

Q. We have heard that the SQL-3 standard has some ODB capabilities
   defined in it. Is that really so? What might be the impact on
   mapping an object model to RDB?

A. [Peter and David]  Don't know.

Q. Why are object databases not very popular for business apps?

A. [Peter] RDBs are at the heart of building business systems.
   The common technology for business apps is the use of an RDB.
   More common than any one language. More common than any one
   operating system.

   Moreover, the content of an RDB represents very significant
   value to an organization. Few organizations could survive
   any major disruption of that content.

   Yet I see increased interest in this area; time will tell.

   [David]  They are new and don't have a track record. The
   companies that offer them are (relatively) small. This all
   adds up to perceived risk. However, there are many business
   that are starting to use them and I expect that to increase.

   [Ken] Yes, this is a case of history repeating itself. Many
   business systems support high transaction rates (lots of
   updates) and/or large volumes of data (lots of rows in
   tables). A dozen years ago this very same concern generated
   resistance to relational systems. The new database technology
   will need time to mature and become more robust and more
   efficient (and supported with all necessary maintenance
   utilities) before it will gain significant market share.

Q. What ODBs would you recommend for business applications?

A. [Peter and David] ObjectStore, Versant, Gemstone.

Q. DMserver takes care of application connect and disconnect with
   a database.

   Who handles the open and close of each table in the database?
   Each DM object? How often -- each time a DM object needs to
   interact with the database? Or?

A. [David] In SQL you don't open or close tables. If you did, a
   DM object would handle it, though.

Q. Many-to-many object connections:
   Is adding a correlation class the only way to implement this?
   Is there another way?

A. [Peter] A transaction class (or a transaction class with no
   attributes, called a correlation class) is needed.

   [David] You have to have the table in the RDB to contain the
   information about the connection. The easiest way to use this
   table is to add a class to the object model. The only other
   choice is to make your dmObject smart enough to know about the

Q. Are there any other responsibilities for the DM object, to map
   PD objects to database tables? Can they or should they provide
   other services?

A. [David] Yes, the DM objects have the responsibility to do the
   mapping and you may implement several services to accomplish
   this work. In addition to the mapping, the DM objects do the
   actual communication with the database using SQL for load,
   save, delete. DM objects may have special services to support
   specific database requests. DM objects also make sure that
   there is only one of a given object in memory.

   [Ken] I prefer to resolve every many-to-many relationship in
   the model by injecting a correlation class into the
   relationship. Often there will be some additional responsibility
   for the correlation class, and the explicit use of such a class
   helps in the discovery. These correlation objects must also be
   persistent if the others are.

   Consider an example. A person may enroll in several workshops.
   Each workshop may have a number of persons enrolled. Thus, 
   we recognize a many-to-many relationship between "person" and
   "workshop."  We might choose the name "enrollment" for a
   correlation class, placed between the "person" and the
   "workshop" classes. The constraints on the enrollment class 
   indicate exactly one person and one workshop.

   Now imagine this possibility: We could be asked, later on, to
   also keep track of the enrollment date for each specific
   pairing of person and workshop. If we have already identified a
   correlation class, we know exactly where to place the
   responsibility for the enrollment date. The correlation becomes
   a transaction class for each specific enrollment event

Q. If you have several databases, and you have to access them
   within a single application, would the DM objects take care
   of all of the concerns of dealing with multiple databases?

A. [Peter] Yes. Very helpful to use a class library that
   supports all of them consistently (e.g., Rogue Wave's

   [David] Yes, this should be encapsulated in the DM objects.
   You will probably have to do special work to have connections
   to multiple databases at a time, especially if they are from
   different vendors. Peter is right; library support for this is

Q. If you are building a distributed system, is there a good way
   of distributing objects among the processors? Guidelines?

A. [Peter] Low coupling, high cohesion -- so distributing
   in light of groups of interacting objects is helpful.
   You make best engineering judgments; implement; and
   then adjust again and again.

Q. What is the status of distributed business systems in the US?
   In the conferences, we hear a lot about distributed object
   systems. Yet are they really used in business apps at this point?

A. [Peter] Mostly just client-server, with objects on the client
   and RDB on the server. Oracle has placed venture funding
   in a firm that is developing an object database for the client
   side, specifically supporting this concept (the startup is
   called Omniscience). Another company we're watching is Persistence
   (promising yet very pricey).

   [David] I have worked with client-server apps (multiple
   machines, multiple databases). Yet distributed is certainly
   more than client-server. Work is being done in this area by
   some of the larger companies. Many conference speakers talk
   about such matters, yet it takes a while for most businesses
   to sort things out and apply new technologies.

Q. Who checks constraints, upon exiting a field?
   A PD object? Seems reasonable.

   Yet another approach is to do type checking and format
   checking (at least, simple checking of values) within
   the human interface. In fact, certain class libraries
   support such data entry checking.

   So, it seems like HI objects could do basic field checking
   and then let PD objects do more detailed checking after that.


A. [Peter and David] Let the HI object do that which is easy:
   type, size, range, and mandatory/required (for example, 
   a person's last name is: string, 20, alpha, mandatory).

   Let PD objects check for inter-attribute consistency and
   algorithmic checks (checking to make sure that the next
   assignment does not put an employee over an agreed-upon
   maximum number of active assignments).

   [Ken] When a conflict arises, an HI object will have the 
   responsibility to notify the user about the specific
   problem. You may be able to guide the user toward
   correcting it by taking some subsequent action. In some
   RDB's, you can assert referential integrities (data
   dependencies between objects). If the RDB raises an
   exception, the DM object may have to detect that by
   checking the results of each update query. When a
   transaction fails, the DM object would most likely notify
   its corresponding PD object. Then, the PD object can alert
   the HI object which had initiated the sequence.  When RDB
   integrities aren't available, put the logic into the PD
   object, where it will be most apparent (and least

Peter Coad
  Object Intl, Inc. Education-Tools-Consulting. Founded in 1986
    "Helping teams deliver frequent, tangible, working results"
     8140 N MoPac 4-200, Austin TX 78759 USA
     1-512-795-0202 fax 1-512-795-0332
     direct line 1-919-851-5422 fax 1-919-851-5579
  FREE newsletter. Write majordomo@oi.com, message: subscribe coad-letter
      coad@oi.com   info@oi.com   http://www.oi.com/oi_home.html
  pgp: 3DBA 3BDD 57B6 04EB B730 9D06 A1E1 0550 (public key via finger)

DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org