Re: Relational database & OO

Responding to Gagne...

That's one way of doing it. My experience shows that 70-80% of a system is queries. Whether inquiry transactions or reports, all the business systems I've participated coding or designing spent little production time changing data. In the online systems I'm familiar with, update and change transactions were preceded and followed with queries. Long after transactions are done posting, management looks at reports to see how their business is doing. Given statistics like these it makes little sense to design your application or OO model before designing your database.


Note that I was careful to qualify with "non-CRUD/USER".

That sort of proportion is a symptom that the application is USER/CRUD processing. The application is basically a pipeline between the database and the UI and its main purpose in life is to convert between the two views. For that sort of situation the RAD layered model infrastructures already provide lots of automation so an OO approach would probably be overkill by reinventing that wheel.

That seems an over-simplification. Would you characterize an online trading system as CRUD? For every single trade how many queries are performed before and after? For any single banking transactions how many queries before and after? I suppose that when humans are involved they tend to look at what things look like before and after transactions--just to make sure. Eliminate humans and you may still have a 10-1 ratio of logical DB reads to writes.

If 70-80% of the code in the system was related to processing queries, I would have to say that sure sounds like CRUD/USER. But that seems high even for CRUD/USER. Typically there is as much code devoted to presentation of the query data in the UI as there is for formulating DB the queries. For a distributed system one needs netwroking infrastructure as well (though that is sometimes provided transparently by RAD infrastructures). And typically there are at least some relevant business rules and policies between the DB and UI, if for no other reason than error checking.

In terms of the classic layered models used for CRUD/USER infrastructures, the real issue is what goes on the the Business layer. If the code for the Presentation and Data layers dominate the application, then one is in the CRUD/USER realm. Then the Business layer is usually just providing a mapping function from one view to the other.

However, once the code in the Business layer dominates the application, one is out of the realm of CRUD/USER. At that point the layered model breaks down and the Presentation and Data layers just become low level service subsystems. IOW, the model changes to

[Business Problem]
/ \
/ \
[UI] [Data Access]

A priori I would expect an online trading application to be outside the realm of CRUD/USER because the rules and policies driving the various types of transactions are complicated. In fact, I would not be surprised if there were multiple subsystems to be involved in the Business "layer". So I have a problem understanding why so much of the application would be tied up in query processing.

There is also an issue of how important the queries are. In typical IT applications most, if not all, of the business objects needed to solve a given problem are initialized from with data from a DB. To do that initialization one needs to get the data form the DB. But is getting the data from the DB really important to solving the business problem?

I submit that it is not if the business objects exist primarily to apply business rules in some complex manner. That is, simply initializing the business objects is not what the application is about. In an extreme case, suppose one has a single factory object to instantiate objects of each class and each factory has a unique query it uses to acquire the initialization data from the DB. Stepping back a bit, all those factory objects are just infrastructure for the initialization of the objects that actually solve the problem. From that perspective the query processing is quite peripheral to the problem solution even though there is quite a lot of it.

Now take this one step further. If the business objects don't "see" the queries because of decoupling through the factory objects, why not go the next step and decouple the factory objects from the DB queries? The data the factory needs to initialize an object of class [X] doesn't depend on the storage mechanisms; the factory just needs the values. If the factory just asks for the data through a generic subsystem interface, then one can probably implement query construction much more generically.

That is, in the DB Access subsystem one has a very different problem in hand. Now one must map the interface to the persistence paradigm and its Data Model. Often one can come up with much more efficient representations that simplify things.

For example, in the DB Access subsystem one might have a single Query object that knew how to format SQL queries given a set of identifiers and data from the interface and some sort of external configuration data (perhaps in the DB itself) for mapping data. Basically that single object would just plug in values while concatenating a string. Now the problem solution AND the DB access are both simpler. [This is one of the benefits of isolating the DB Access that we discussed in the other subthread.]

IOW, the volume of code tied up in query processing drops dramatically because of abstraction in the DB Access subsystem even though the number and variety of actual DB queries is large. Meanwhile the data access of the problem solution's factories is reduced to a set of simple interface calls with not special knowledge needed.

Additionally, relational data models can be more easily proven correct--or correct enough--before an investment is made in coding.


I'm not sure I buy that. More easily than what? The RDM normalization can be applied beyond the RDB's table/tuple paradigm. ISAM files, CODASYL files, and other data representations can be normalized using the same basic rules. And OO Class Models are routinely normalized as part of the basic paradigm methodology.

However, I don't see that as being very relevant.

I guess the point was relational DBs have at least relational calculus behind them, and we can always ask a design a) is all the necessary data saved and b) are all the relationships represented?

Granted this is anecdotal, but the experienced DBs I've known would all end up at nearly identical DB designs given the same requirements. I've not seen that consistency with OO designers.

That's true, but the OO designer is dealing with a much bigger problem because of the need for behaviors. The Data Model only needs to worry about data while the Class Model is just one <static> piece of a much larger, largely dynamic structure.

Lastly, your database is language-neutral. It shouldn't matter what language the application sitting in front of the database is written in, or even what paradigm it's born from. Flexibility starts with a good database design and extends through the application--not the other way around.


That's true enough but I would make it even stronger. RDBs are designed to be problem-independent, not just language independent, which is pretty much my point.

I missed that, but now I'm interested in what you mean by "problem-independent." If you're referring to the RDB before a DB design is given it, then I think I understand what you're talking about.

The RDB paradigm optimizes for ad hoc queries. That is, the RDB needs to provide access to the same data for a lot of different purposes (i.e., different problems being solved by different client applications). To date the RDB is the most efficient means of providing that sort of very generic access.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Made in the USA
    ... A person builds a plane, He likes the results but decides to design ... Now you write your business plan. ... factory, but I also beleive that companies like Van's didn't start out ...
    (rec.aviation.homebuilt)
  • Re: Relational-to-OOP Tax
    ... burden of proof to support that claim in the context of behavior ... your presentation and business rules. ... good interface design is difficult. ... with multiple paradigms simultaneously, choosing the techniques best ...
    (comp.object)
  • Re: OO Design induces an existential crisis
    ... You call yourself an experienced business applications ... that is pretty good for meeting the principles of both OO design and SOA ... If they are reading one of my articles, they are probably a developer ... a function point counter and a cost wonk, ...
    (comp.object)
  • Re: How should I generate a primary key?
    ... Obviously the designer did not get all of the business rules from the ... Should the database ... A Work Order records the transaction of a truck service at a given ... This has got nothing to do with bad design, it is about the developer trying ...
    (comp.databases)
  • Re: XP Requirement Analysis?
    ... When an existing design needs to be encoded via TDD, ... could have generated the TDD principle. ... The interface _does_ come first. ... to buy a business value. ...
    (comp.object)