| |
The main focus and goal of this book is to provide a practical, usable guide for database professionals that introduces the use of the UML for database design. The design of a database requires a combination of many groups within an organization, including the customer or end user, business analysts, architects, developers, database designers, database administrators, and many more. However, in our case study we have focused on the database design team, which has now begun to see the final results of its hard work.
Although we have shown how the UML can be used for database design, don't get caught up in a panic thinking that there is a new language you now need to learn and that you cannot use the UML for database design until you are an expert in all aspects of it. If you believe that, you will never get going.
Although the UML is a thorough language for complete application and database design, it does not mandate a strict process that must be followed throughout. If you are ready to build the database design but don't know all about the UML, you can start with the logical design or even the database de sign models and skip the rest. Or you can use information that has already been captured to build these designs.
Although you may not build all of the models, all the project phases should always be covered no matter whether they are modeled or not. For example, the information captured in use cases and activity diagrams needs to be uncovered somewhere and somehow. It may be in a textual document or just in a meeting discussion that leads up to the creation of the logical and database designs. One way or another this is work that must be done if your project is to be successful.
The power of the UML is that it is there for you when you need it, but it is also lightweight enough to get out of the way when you need it to. There are many books that describe various processes of using the UML, but unlike some methodologies, the UML is a flexible language. You can use what you need when you need it and continue moving forward as necessary.
You may recall the process overview shown in Figure 9-1. We used it at the start of the book to show how this book would proceed through the modeling process. Obviously, this is just a slice out of a larger development process that also includes testing and deployment. Let's use this figure to summarize how the database design process can be accelerated, as we have discussed throughout the book. In Figure 9-2 we can see the development artifacts listed that are created very early in the development process (during conceptual modeling). These early artifacts can then prepopulate the subsequent development phases. These artifacts can provide a jump start to your development team and thereby not only accelerate your development but also improve your system quality.
If you have existing legacy artifacts (databases, code, and so on), these too can help jump-start your database design. Why reinvent the wheel when these existing assets can be reverse engineered into your models? (See Figure 9-3.) Not only does this avoid redundant work, it also provides artifacts that are already operationally proven. Once again, here we have another way to speed development and improve quality.
| |