Rating: 
Summary: Great understanding for all facets of DB Design
Review: Despite the previous reviews of this book I decided to read it and am glad that I did. The authors took me through a thorough yet easily understood path of both UML and database design. Not being an expert in UML, but having a background as a data analyst, I found the book useful to understand UML as it pertained to how I would use it. The callouts for database designers were very helpful and by following a consistent real-world example, I was able to understand how I would design my databases using the UML. I now understand that I don't have to know or even use the entire language to succeed, but only the parts that are relevant at the time I am designing and now I can be on the same page as my development team too.
Rating:
Summary: Great understanding for all facets of DB Design
Review: Despite the previous reviews of this book I decided to read it and am glad that I did. The authors took me through a thorough yet easily understood path of both UML and database design. Not being an expert in UML, but having a background as a data analyst, I found the book useful to understand UML as it pertained to how I would use it. The callouts for database designers were very helpful and by following a consistent real-world example, I was able to understand how I would design my databases using the UML. I now understand that I don't have to know or even use the entire language to succeed, but only the parts that are relevant at the time I am designing and now I can be on the same page as my development team too.
Rating: 
Summary: Needs a revision
Review: I am halfway through this book, which was given to me by a design team member. I agree with a previous reviewer that this book is too long and has numerous opaque passages. It is a narrative of a presumably fictitious project, and must therefore be read from beginning to end. Given enough time, that would be OK, however my reading list for software engineering already has several books waiting in a holding pattern.It is useful to compare this book with related works that readers might hope to complement their database design and implementation work. Database Programming with JDBC and Java (G. Reese, O'Reilly) is more concise and more practical to read one or a few chapters at a time, intercalated with other readings. It also includes mention of design patterns in the object oriented design of persistent objects, a serious omission in Naiburg and Maksimchuk. Reese does not delve much into database design proper, which is why one might want to have Naiburg and Maksimchuk handy. Unfortunately, they don't complement each other that well. Building Object Applications that Work (Scott Ambler, Cambridge Univ. and SIGS Press) is a much better introduction to object oriented analysis and design, and provides a simple (though not necessarily ideal) means to persist objects to a database. If you are in a horrendous hurry to learn a way to do it, Ambler's book would be better. Beware: Scott Ambler is an opinionated guy. The authors also introduce a few notational elements to the UML to distinguish business actors and use cases from their non-business counterparts. Oddly enough, these notations don't appear in Rational Rose, presumably one of the tools the authors use given that the book is part of the Booch Jacobson Rumbaugh series. This book could be improved in a future edition by:
1) De-emphasizing the lengthy narrative of the example project
2) Avoiding UML notation that is not available in commonly used tools such as Rational Rose and Together ControlCenter
3) Detailed discussion of strategies for mapping design patterns for persistent objects to database design, and
4) Cleaning up the prose and removing lengthy and uninformative passages, some of which must have been written either at wee hours of the morning or with a Damoclean publishing deadline hanging over the authors' heads. The book is useful, but neither a must-have nor a source of rapidly deployable knowledge.
Rating:
Summary: I really liked it!
Review: I wanted a book that would show how to start using UML for data modeling. This did. I too liked the DB Designer sidebars and the detailed case study. I thought the case study "story" sections were a nice change of pace from most software books' straight technical style. (And I've see such stories happen on the job too often.) This book worked for me.
Rating:
Summary: I really liked it!
Review: I wanted a book that would show how to start using UML for data modeling. This did. I too liked the DB Designer sidebars and the detailed case study. I thought the case study "story" sections were a nice change of pace from most software books' straight technical style. (And I've see such stories happen on the job too often.) This book worked for me.
Rating:
Summary: I really liked it!
Review: I wanted a book that would show how to start using UML for data modeling. This did. I too liked the DB Designer sidebars and the detailed case study. I thought the case study "story" sections were a nice change of pace from most software books' straight technical style. (And I've see such stories happen on the job too often.) This book worked for me.
Rating: 
Summary: overpriced brochure from Rational Corp
Review: In the grand tradition of Rational Corp - this is an overpriced book from Rational Corp to complement its overpriced software. I must commend the HealthCare example in the book that is described in fair detail. The book's website is empty and does not supplement the book's content - only contains a link to order the book and an email to contact the authors. If you have to buy it, buy a used copy or read the free marketing stuff on the Rational website.
Rating:
Summary: Not Enough Of What It Is Supposed To Be
Review: Less than half of this book really deals with what the title suggests. Chapters 6, 7, and 8 are the only things of value to someone already familiar with the UML. The previous chapters try to give the database designer an overview of using UML for all project aspects; however, this is done much more cleanly in other books like UML Distilled or Visual Modeling With Rational Rose 20XX and UML. The authors also present things with assumptions made about how the organization is structured: separate application and database design teams. This slant requires that the reader translate what is written to their particular situation. A more useful book would have stated principles that can be applied to various organization structures with appropriate practices. Also, there is no advice given as to how to actually implement any of these UML extensions for database design in the available tools. This makes the ideas presented hard to put in practice and makes the book much more theoretical than practical. Bottom line, there is not enough unique information here for the book to stand on its own. It would be better to roll this information into texts like the ones I mentioned at the beginning, and also give examples using currently available tools.
Rating:
Summary: Not Enough Of What It Is Supposed To Be
Review: Less than half of this book really deals with what the title suggests. Chapters 6, 7, and 8 are the only things of value to someone already familiar with the UML. The previous chapters try to give the database designer an overview of using UML for all project aspects; however, this is done much more cleanly in other books like UML Distilled or Visual Modeling With Rational Rose 20XX and UML. The authors also present things with assumptions made about how the organization is structured: separate application and database design teams. This slant requires that the reader translate what is written to their particular situation. A more useful book would have stated principles that can be applied to various organization structures with appropriate practices. Also, there is no advice given as to how to actually implement any of these UML extensions for database design in the available tools. This makes the ideas presented hard to put in practice and makes the book much more theoretical than practical. Bottom line, there is not enough unique information here for the book to stand on its own. It would be better to roll this information into texts like the ones I mentioned at the beginning, and also give examples using currently available tools.
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.
| 
