• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Refactoring databases: top-down vs bottom-up

 
blacksmith
Posts: 979
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You may find this of interest:
Agile Data: The Cultural Impedance Mismatch Between Data Professionals and Application Developers
 
This is my favorite show. And this is my favorite tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic