UML for Database Design [Paperback]

Eric J. Naiburg (Author), Robert A. Maksimchuk (Author)

Book Description

ISBN-10: 0201721635 | ISBN-13: 978-0201721638 | Publication Date: August 3, 2001 | Edition: 1

Typically, analysis, development, and database teams work for different business units, and use different design notations. With UML and the Rational Unified Process (RUP), however, they can unify their efforts -- eliminating time-consuming, error-prone translations, and accelerating software to market. In this book, two data modeling specialists from Rational Software Corporation show exactly how to model data with UML and RUP, presenting proven processes and start-to-finish case studies. The book utilizes a running case study to bring together the entire process of data modeling with UML. Each chapter dissects a different stage of the data modeling process, from requirements through implementation. For each stage, the authors cover workflow and participants' roles, key concepts, proven approach, practical design techniques, and more. Along the way, the authors demonstrate how integrating data modeling into a unified software design process not only saves time and money, but gives all team members a far clearer understanding of the impact of potential changes. The book includes a detailed glossary, as well as appendices that present essential Use Case Models and descriptions. For all software team members: managers, team leaders, systems and data analysts, architects, developers, database designers, and others involved in building database applications for the enterprise.

Editorial Reviews

From the Back Cover

The Unified Modeling Language (UML), the standard graphical notation for modeling business and software application needs, has emerged as an effective modeling tool for database design. When used as a common modeling language for the many facets of system development, the UML can serve as a unifying framework that facilitates the integration of database models with the rest of a system design.

This pragmatic guide introduces you to the UML and leads you through the process of UML-based database modeling and design. The book presents the different types of UML diagrams, explaining how they apply to the database world, and shows how data modeling with the UML can be tied into the Rational Unified Process.

UML for Database Design is structured around the database design process: business use case modeling, business object modeling, database requirements definition, analysis and preliminary design, and, finally, detailed design and deployment. For each phase of development the book describes the overall objectives and workflow of that phase, the status of the case study, the relevant UML constructs, and the nuts and bolts of database modeling and design with the UML. Drawing on their extensive industry experience, the authors reveal the trials and tribulations of database development teams, lessons learned, and pointers for success.

Topics covered include:

• The business use case model
• Activity and sequence diagrams for modeling database functions and tasks
• Moving from the business to system model
• Class diagrams and statecharts
• Mapping classes to tables
• Transformation of attributes
• Rational's UML Profile for Database Design
• Creating tables from classes
• DDL scripts, component diagrams, and deployment diagrams
• Jump starting the database design process

A case study runs throughout the book to illustrate key concepts and techniques, and appendixes containing the actual UML models from this case study are used to catalog the type and extent of models that would be developed for such a system.

Practical, concrete, and based on real-life experience, UML for Database Design brings you exactly the information you need to begin working with the UML and take full advantage of the technology for high-quality database modeling and design.

0201721635B06292001

About the Author

Eric J. Naiburg is a product manager for Rational Software Corporation, focusing on the Rational Rose product line. His professional focus is on extending the ability of Rational Rose to support database design and object-relational mapping within the Rose visual modeling tool and the UML. He delivers numerous popular seminars on the topic.

Robert A. Maksimchuk is the Data Modeling Evangelist for Rational. He is a frequent speaker at Rational events, various database conferences, and user groups worldwide, and has more than twenty-four years of experience in the software development field.

0201721635AB06272001

See all Editorial Reviews

Product Details

• Paperback: 320 pages
• Publisher: Addison-Wesley Professional; 1 edition (August 3, 2001)
• Language: English
• ISBN-10: 0201721635
• ISBN-13: 978-0201721638
• Product Dimensions: 9.2 x 7.4 x 0.6 inches
• Shipping Weight: 1.1 pounds (View shipping rates and policies)
• Average Customer Review: 3.0 out of 5 stars  See all reviews (6 customer reviews)
• Amazon Best Sellers Rank: #1,499,475 in Books (See Top 100 in Books)

Customer Reviews

Most Helpful Customer Reviews

34 of 37 people found the following review helpful:

1.0 out of 5 stars Spend your time and money on another title, December 20, 2001

By 

Vince Kenyon (Chicago, IL USA) - See all my reviews
(REAL NAME)   

This review is from: UML for Database Design (Paperback)

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.

8 of 8 people found the following review helpful:

5.0 out of 5 stars Great understanding for all facets of DB Design, December 24, 2002

By 

Chuck (New York) - See all my reviews

This review is from: UML for Database Design (Paperback)

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.

13 of 15 people found the following review helpful:

3.0 out of 5 stars Needs a revision, January 8, 2002

By 

H. Hemken (San Jose, CA United States) - See all my reviews
(REAL NAME)   

This review is from: UML for Database Design (Paperback)

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.