How to conciliate OOAD and Database Design?

Question

Recently I've studied object oriented analysis and design and I liked a lot about it. In every place I've read people say that the idea is to start with the minimum set of requirements and go improving along the way, revisiting this each iteration and making it better as we continuously develop and contact the customer interested in the software. In particular, one course from Lynda.com said a lot of that: we don't want to spend a lot of time planning everything upfront, we just want to have the minimum to get started and then improve this each iteration.

Now, I've also seen a course from the same guy about database design, and there he says differently. He says that although when working with object orientation he likes the agile iterative approach, for database design we should really spend a lot of time planning things upfront instead of just going along the way with the minimum.

But this confuses me a little. Indeed, the database will persist important data from our domain model and perhaps configurations of the software and so on. Now, if I'm going to continuously revisit the analysis and design of the model, it seems the database design should change also. In the same way, if we plan all the database upfront it seems we are also planning all the model upfront, so the two ideas seems to be incompatible.

I really like agile iterative approach, but I'm also looking at getting better design for the database also, so when working with agile iterative approach, how should we deal with the database design?

Answer 1

The problem with databases is that they contain data. This means that if you want to change the structure of a database, you need to cope with all the data therein, making sure to maintain its integrity from the orignal schema to the revised schema.

That's not always easy. It introduces risks. Data migration between schema changes can be difficult to test. Basically, databases can be developed iteratively, but doing so tends to be a pain in the butt.

Code, on the other hand is much easier to change. So long as you have tests in place, it's reasonably straightforward to determine that refactored code still does the same thing as the original. Thus refactoring and iterative development works well on program code.

There's no definitive answer to reconciling these items. I'd say the advice you've been given is good--try to minimize the number of times you restructure your database. This doesn't mean you can never change your DB, just don't do it all the time. Try to predict the changes you'll need over several iterations and update the schema once for every 3 or 10 coding iterations. Think of database schema changes as part of your major version releases while code changes can be dot releases.

Answer 2

The trick is in the way you approach the data persistance end of your code. I like keeping it iterate on all fronts.

If you maintain a good model of the database (I like to do that with MySQL Workbench) and have a sensible solution for persistence (I like to use JPA), then you can change and redeploy database and all related code with relative ease.

Sadly, the traditional approach is partial to getting all of the information so as to get the full data model ready, thus spending a long time before the working prototypes can be written.

A middle ground is the following: have as many forms used in the process being automatized as possible have its persistence defined, and iterate with the rest of the data base structure (views, stored procedures and auxiliary tables).

Answer 3

I understand it got you confused. You can not build a complete datamodel when you will only start of by building a minimal set of features in your solution.

A good approach is to apply good design to the initial datastructure. If your design was good, all later additions will not require a redesign of your initial structure (there are some exceptions!). Make sure to read about DB Normalisation

What you will notice in an iterative software development process is that the datastructure will grow with the amount of requirements you have build in your software. In later phases of a software development process, the amount of requested changes lessens, so changes to the datasource are less likely aswell.

When a big change is imminent, there is some magic you can do to diminish the redesign needed. For instance, you can leave an existing datamodel untouched, and build some custom mapping in a abstract layer of your solution. Most of todays ORM's are very suitable for this.