Summary

This chapter started with a discussion of the different ways to model databases and how they all show pretty much the same things, no matter what your notation. We demonstrated the similarities between IE, IDEF1X, and UML and how each depicts the same models in a different way.

From the understanding of different modeling types, we entered into the view that no matter what your role, you should involve everyone in software development, whether they are analysts, developers, architects, or database designers, and that each member must have a common understanding and work together to define each element. By working together, you ensure that different groups are not, for example, using the same name to describe a different thing (or vice versa) and also that they can reuse each other's work. Whether you decide to use UML for your database designs or not, leveraging the work of others has tremendous value. Having the database designers understand UML and the work that the analysts and architects have defined will enable the database team to jump-start their designs and ensure that the requirements uncovered for the project are common across the teams.

We then looked at how to create conceptual, logical, and physical data models using the UML. We started with business analysis models to create the conceptual and moved into class diagrams for the logical and physical. Several stereotypes are available in the UML for database design. These stereotypes are used to both visually describe and provide additional properties to these stereotyped elements, enabling database design.

Overall, whether you select to model the database using UML or just decide to leverage what already exists from other teams, understanding UML has great value. Keeping teams synchronized and driving toward common goals is what database applications need to succeed.