Scott Ambler is uniquely qualified to write this book. He started his software life as a data modeler, and is now an industry thought-leader in agile, object-oriented software development practices. He wrote Agile Database Techniques to address a single issue that he is obviously passionate about: is it possible for data professionals to develop their data in an evolutionary way? Ambler answers this question with a resounding "yes"! And his book is a manifesto on how the data and object communities can lay down their weapons and join forces to create better software.
Part One addresses the basics of agile development, database concepts and data normalization, object concepts and object normalization ¯- which may be a new concept to some readers. If you are not a data person, you will get a good introduction to the data world-view. If you are not an object person, you will gain insight into why object people see the world from a behavioral view, not the data-centric view. What I found appealing was Ambler's willingness to leave out all the fluff and deliver just enough detail to equip us to move to the next part of his presentation: Evolutionary Database Development.
This second part of the book covers *a lot* of ground. After a well-crafted appeal for flexibility as a major success factor in software development, Ambler introduces the principles and practices of his own "Agile Model-Driven Development" approach, then a concise discussion of Test-Driven Development, also known as "test-first programming". This is a very brief chapter, and I wish Ambler had developed these concepts a bit more, but he has much bigger fish to fry in this book. His discussion of the need for, and practices of, database refactoring will be provocative for many data people. In my own consulting experience the "rot" or "smell" of database entropy is everywhere. The rigor of the original data models is lost under the pressure of schedule, or the inertia of inexperienced persons not taking the time to think about the downstream effects of reusing a table column for an obscure and transient purpose...which soon becomes permanent. The most significant chapter in the second part discusses mapping objects to relational databases. Ambler has written often and extensively about the object-relational "impedance mismatch", and this chapter offers the programmer and DBA much to think about.
A theme that runs throughout the entire book is what Ambler calls the "role of the agile DBA". These brief discussions, almost sidebars in their presentation, are aimed squarely at DBAs working on agile, OO projects. Most OO developers will kill for a DBA who actually supports the software effort rather than being an institutionalized impediment. Ambler's tips to the "agile DBA" are worth the price of the book, IMHO.
Part 3 is a collage of database concepts that are essential for software developers to understand if they are to be successful as a programming and data team. The topics include referential integrity, access control, concurrency issues and control, transactions and their ACID properties, with a brief discussion of both database transactions and object transactions -- and they are not the same. Very important stuff, and it is my experience that many application programmers have only the barest understanding of these critical technical issues--especially data-specific issues such as two-phase commits. It's all here.
The last part of the book reflects the beginning: how can you become agile, and how can you bring agility into your organization? Ahh, this is going to be hard for some people, and some companies. But it can be done, if approached patiently, with sensitivity for your existing corporate culture. And the reality of the cultural mismatch is something Ambler addresses throughout this book. This is why he calls the agile DBA a "peacemaker". This is why he calls upon us to be "generalizing specialists", so we can see that there is more to software than objects, and certainly more than data alone.