Rating: 
Summary: Spend your time and money on another title
Review: Like the time to read it, the money to purchase this book could be better spent.The problems begin with the title. It indicates a focus on artifacts of design, while the book focuses largely on the process of design. And not just database design. The authors tell the story of a complete project lifecycle in which, they claim, the database designer should participate. I should rather have thought that UML might allow the different specialists of a development project to communicate asynchronously, sparing them from having to slog through all of the work together. At any rate, I doubt whether many organizations can afford to pay DBAs to sit through requirements workshops with users and customers. I like the "Database Designer" sidebars explaining how specific facts relevant to database design can be inferred from various UML artifacts, but all of these combined cover only a few pages. For my taste, the authors waste far too many words narrating (with named characters) the story of how the artifacts get built. Just tell me how to read them and how to use them for database design. Fifty pages tops. Just after page 100, the authors finally get down to database design with a discussion of how to map an object model to a data model, spoiled only by the following comment: "It is good practice to have additional columns in an association table over and above the foreign keys based on the relationships with the parent tables. If you don't have a need for additional columns, generally you do not need the many-to-many and can just create a one-to-many relationship or an additional table that is not really an association table (p. 106)." That's news to me. And to most other database designers, too, no doubt. The authors continue in the same vein when defining the term Non-identifying Relationship as "a relationship between two tables in which each table can exist independently of the other," and Identifying Relationship as requiring that " . . . the child table must coexist with the parent table (p. 125)." Experienced database designers will note first that the coexistence involved here is between rows, not tables. Second, they will note that the authors have confused identity with existence, since there are relationships requiring coexistence (of rows) that do not identify. You will find the same inaccuracy in the online documentation of Rational Rose Data Modeler, in which these authors presumably also had a hand. Besides other errors and peculiarities, there is the occasional inane comment: "It is important to have the database running at full speed all the time; this can be accomplished by having a well-designed database and taking advantage of specific DBMS properties. Running the database with the correct amount of storage helps keep the database running at its best (p. 152)." Now there's a hot tip. Most annoying of all, however, is the proliferation of descriptions that explain nothing: "After the intense mining of already captured information and using much of their own knowledge of database design and experiences building several other databases, the database designers make some decisions on how to build the database storage in tablespaces. The team determines that there is a need to have five different tablespaces . . . (p. 164)." There is no exciting climax explaining how they came up with five. I could have cited numerous similar passages, but instead I will close with the observation that there are almost 100 pages of appendices containing the UML artifacts that these designers produced.
| 
