File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Refactoring databases: top-down vs bottom-up Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Refactoring databases: top-down vs bottom-up" Watch "Refactoring databases: top-down vs bottom-up" New topic
Author

Refactoring databases: top-down vs bottom-up

Gian Franco
blacksmith
Ranch Hand

Joined: Dec 16, 2003
Posts: 977
Dear authors,

Recently I've been working on a project
for which the datamodel has been developed
in a top-down fashion (i.e. use-cases,
sequence diagrams, ..., data model)

Some of the reviewers in the project would
have preferred a bottom-up approach especially
when old data had to be cast in the new
datamodel.

In your opinion what are the merits of both
approaches? And secondly, can refactoring
on the database level solve or mitigate these
design issues?

Kind regards,

Gian Franco Casula

[ July 25, 2006: Message edited by: Ilja Preuss ]
[ July 25, 2006: Message edited by: Gian Franco Casula ]

"Eppur si muove!"
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
Originally posted by Gian Franco Casula:
Dear authors,

Recently I've been working on a project
for which the datamodel has been developed
in a top-down fashion (i.e. use-cases,
sequence diagrams, ..., data model)

Some of the reviewers in the project would
have preferred a bottom-up approach especially
when old data had to be cast in the new
datamodel.

In your opinion what are the merits of both
approaches? And secondly, can refactoring
on the database level solve or mitigate these
design issues?

Hi Gian,

The problem with developing a system from the database "up", is that it works perfectly for the techies. One thing that we are all aware of is that the technical solution rarely meets the user's (client's) needs. Most modern approaches to developing software, e.g. RUP, Agile methodologies, etc., focus on developing a system from the users perspective - not from the perspective of a particular subsystem/component of the system itself. It is important that we get the right system working rather than the (incorrect) system working right. It is a clich´┐Ż but "How often has the customer stated 'The system you built works perfectly, it is just not what I wanted'".

Developing a system from the user's perspective should highlight all data that is core to the business logic, but at the same time deliver the correct functionality that the user needs.

If a legacy database already exists then one approach is to use is to use an ORM layer like JDO to map the objects - which have been identified as fulfilling the users needs for the functionality of the system - and their fields, to the existing database. You may find that there are some fields in the database which were never needed, or you may find that there is some information that was not thought of when the database was built which needs to be added.

If the database is used by other applications then you may be limited in the refactorings that you can apply and may have to leave the system as it is.

If the database is used solely for the new application then there are two approaches you could use :
1) Treat the system as if no database existed. Create a new database schema based on the user-centric design. You will then need to migrate the data from the existing database to the new schema. Having the ORM layer mappings will aid greatly in this case. The advantage here is that the new application was developed (objects and their interactions) without changing the existing database. Therefore the functionality of the application can be tested without changing the database layer. If there was an old application using the existing database, then comparisons can be made between the old application and the new application - where their functionality overlaps.

2) Use the existing database and apply small refactorings (remember to test comprehensively after each refactoring), until the desired database schema is produced.

Any refactoring of the database schema will likely involve refactoring the ORM mapping as well.

I would use approach 1) above if the old database was a non-RDBMS datastore, e.g. Clipper, and the new application uses an RDBMS, e.g. mySQL / Oracle. A variation on this could be to recreate the non-RDBMS structure in the new database, and then apply approach 2) to refactor the database towards the desired database schema.

Hope this helps,

Fintan
[ July 25, 2006: Message edited by: Fintan Conway ]
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
You may find this of interest:
Agile Data: The Cultural Impedance Mismatch Between Data Professionals and Application Developers
 
wood burning stoves
 
subject: Refactoring databases: top-down vs bottom-up