This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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?
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.