UML for Database Design?
Yes, database design can be accomplished using the UML. The UML itself was originally created with an understanding of traditional database modeling. The UML's creators indicate that they consider UML to be a superset of database design methods. Formalized modeling of databases has been widely accepted for years, while application modeling in general is still not as widely followed formally by organizations. It is often thought of as an activity only done formally when describing complicated application architectures. The creators of the UML were able to leverage work that had been done in the past to create the database design standards and that had wide acceptance by the industry to help them drive their creation of the UML.
Not only can you build conceptual, logical, and physical database models using the UML, but you can also bring teams together by sharing a common approach and language. One of the most common causes of application failure is poor communication. If you can have the database designers, application developers, and others working together to design a complete solution, your odds of success increase. A database designer might not build all the UML diagrams that we have discussed in the previous chapters, but he can leverage them to ensure that everyone is following, understanding, and working with the same set of requirements, business processes, assumptions, and decisions. This increases the team's efficiency.
So, does this alone mean that the UML can support database design? No, this information alone does not mean the UML can support database design, but as we continue throughout this chapter, you will come to understand that yes, UML can be and is used for database design. Although we will cover some of the basics for using UML to design databases, we will not go into the depth needed to fully complete the task. For more discussion and much deeper detail on using the UML for designing databases, take a look at our book UML for Database Design (ISBN: 0-201-72163-5).
The Fallacy About Notations
We have spent a lot of time traveling the world, talking about the UML and how it applies to database design. These meetings, presentations, and discussions always start with an explanation that the UML is a language that includes a notation that can be adapted for most types of modeling, including database design. The first ten minutes are spent providing an understanding of how UML can support database design just like any other notation.
IDEF1X (Integration Definition for Information Modeling) is a well-known database design notation that was originally developed for the U.S. Federal Government and subsequently was adopted as an industry standard. IE (Information Engineering), also known as crows feet notation, is probably the most widely used notation.
It doesn't really matter what notation you use; the end result is going to be the same—a good design should result in a high-quality database. In the same light, any notation used in creation of a poor design will create a low-quality database. What is most important is that you can enforce and communicate your designs using the notation you choose. In Figures 6-1, 6-2, and 6-3, you can see how different notations show exactly the same thing. They may look a little different, but they express the same concept.
Figure 6-1. IDEF1X.
Figure 6-2. Information engineering.
Figure 6-3. UML.
A major advantage you gain with using UML for designing databases is that model reviewers, even those with limited technical knowledge such as line of business owners, find it easier to read than other languages. For example, because UML spells out the cardinality (also known as multiplicity, represented by the little numbers on the association lines) directly on the relationship, you do not have to infer what the different types of line markings mean. You just read the relationship.
It's fallacious to assume that UML cannot be used to model databases. The previous examples refer to a logical data model, but the same thing can be done in exactly the same way for physical data models. As the chapter continues, we will demonstrate the use of UML for conceptual, logical, and physical data modeling.