Acknowledgments

Thanks first to God without whom none of this would be possible.

Thanks to Paul Becker, Jessica Cirone, Elizabeth Ryan, and Ross Venables of Addison-Wesley for their invaluable assistance in the overall process.

Thanks to all our reviewers who kept us walking the straight and narrow path . A special thanks to Mike Engle, one of the best System Engineers and OO practitioners in the business. His thorough and relentless technical review added immensely to this book.

Thanks to Jim Conallen, Kevin Kelly, Terry Quatrani, Davor Gornik, Jeff Hammond, and Steve Rabuchin for their valued advice.

Thanks to Lisa Connelly and Mary Cicalese, who helped to make the opportunity for me (Eric) to move up in the world come true. Thanks also to Ed McLaughlin, who gave me the chance to prove myself ; without that opportunity, I would not have the knowledge and skill to write this book.

Thank you to the people who have taken part on the data modeling team at Rational Software Corporation, without whom both of us would not have had the ability to prove our vision and see it come to life. This team includes Hong Lee Yu, Scott Schneider, Will Lyons, Tommy Fannon, Kingsley Wood, Barbara Evans, Larry Dunnell, Brian Lim, Bonnie St. John, Deborah Ford, Der Ping Chou, Douglas Robb, Hermant Kolwalkar, Ron DeWolfe, Rose Rosario, Susan Anstey, Teresa Dowling, Xiangmin Wang, Xiang (April) Li, Yi Gao, and Zoe Lin.

And a special thanks to Grady Booch and Jim Rumbaugh.

Contacts

We would appreciate your feedback on this book. If you have questions or comments, please feel free to contact us by email at gurus@UMLforDatabaseDesign.com, or visit our website http://www.UMLforDatabaseDesign.com.

Chapter 1. Introduction

Why Read This Book?

Who Should Read This Book?

How to Read This Book

Why Read This Book?

Systems Development Is a Team Sport

In today's business climate, systems development is a game that you can't afford to lose. Losing the game can literally cost you your entire business. Business analysis, software development, and database teams all need to work together to understand a business customer's problems and to solve them through the software systems they are assigned to create. We do not build systems just for the sake of keeping our jobs. There are valid business reasons for the systems. The typical overall goal is to make the business better (more efficient, more profitable, and so on). Sometimes the problem to solve lies not in the software but in the way a business process is performed. You may be improving infrastructure, customer experience, internal experience, or some type of business process, but it is not just for the sake of adding or changing the systems. There are critical requirements that need to be met, and it is the responsibility of all teams involved to create the best and most economical solution to fulfill the requirements levied upon them by the business.

In most organizations today, the analysis, development, and database teams work for different managers, business units, or other business organizations. Although these teams are separate, they are all working toward a common goal and need to work together. We have witnessed situations where members of the different teams had to be introduced to each other by name during a meeting although they had been working on the same project for years . This is not a good scenario. It causes the communication of requirements, and especially changes to those requirements, to be lost, misinterpreted, or resolved differently by different groups.

Generally you are not just changing one part of the system but also adding different pieces to a constantly changing system as new requirements are uncovered. In other words, software development is an iterative process. As the developers build the applications, they uncover new requirements just as the data base team uncovers new requirements when building the database. These all need to be communicated not only via documents but also visually through models. This enables these requirements to be traced to the different artifacts throughout the development cycle. However, in the past this could not be done easily since there was no common language for all the development teams to use.

The Unified Modeling Language

The Unified Modeling Language (UML) has quickly become the standard language used for modeling business and software application needs. Although it is the standard of the Object Modeling Group (OMG), the UML is not just for modeling object-oriented (OO) applications. A common misconception is that the UML is intended only for OO development and can't be used for other types. However, the UML was designed as a very flexible and customizable language. This allows for many different types of modeling, including models for understanding the business process, workflow of events, sequence of queries, applications, databases, architectures, and more.

Using the UML for database design allows the business and application teams who are already using the UML for their designs to share a common language and to communicate with the database team. A common problem is that business analysts and developers are building enterprise architectures without considering the data and how the data will be affected. Can the database capture the information that is being described? Are there existing systems that already address the business's needs but are unknown to other teams? Do items with the same names mean completely different things? All of these questions lead us to conclude that the database team should be involved at the beginning of the development process, taking part in the initial analysis and continuing all the way throughout the complete development life cycle. With the ability of the UML to design so many different visual models, you can encompass an en tire application and database design using a single language that everyone can share.

While reading this book, you will learn the different types of UML diagrams and how they apply to the database world. You will also understand how other teams may be using these diagrams and how all the teams can share their work rather than working in separate silos , not communicating until it is too late.

Buy on amazon.com >>

Naiburg E.J., Maksimchuk R.A.

<< Previous page

Table of contents

Next page >>