The Workflow

Now it is time for the database designers to start looking at the real physical aspects of the database they have designed. Depending on the development organization, the DBA may get involved or even take over at this point. In some companies, an employee may wear many hats that include both the database designer and DBA, but others may have separate people working on each task. Of course, it depends on your situation, but some teams work together here and others separate this into functions specific to your company's job descriptions. The fact is, it doesn't matter who is responsible for the implementation of the database ”it has to get done, and the UML provides the ability to understand quite well what needs to be done to accomplish the job.

Understanding the deployment of the database is very important and can make the difference between continued maintenance and upgrades or a well-running system that lives for a long time. Modeling the storage of the data and how it will be deployed across multiple servers, drives , and partitions enables easy understanding of growth moving forward. Using the requirements that have been captured in the up-front design of the database and systems helps uncover the size of the database and provides information that enables you to estimate growth over time.

As with any other piece of the database design, you can build the database directly with code and not model the database implementation first, but not modeling the database implementation first can cause failure. It is quite difficult to understand textually or by trial and error how the data will lay out, how large the database will be, how quickly the database will grow, and what types and sizes of hardware are needed to support the database system. The database can span many uses and purposes and can grow out of control quickly. Using the UML to model the tablespaces, which tables reside in which tablespaces and how they partition across tablespaces, and which drives contain which tablespaces and where those drives reside are very important tasks and need to be thought out thoroughly and precisely. UML component and deployment diagrams contain the artifacts that can be used to describe each of these functions and graphically display them. By visualizing the deployment and implementation graphically rather than in text, the database designer can easily communicate the layout of the database, see where there are deficiencies, and understand what needs to be done to deal with the issues.

Using Previously Created Modeling Artifacts

The use cases created in the beginning of the project to facilitate understanding of the requirements for building the database system and the various iterations that take place provide a good start for building the database tables, col umns, and so on. The use cases also provide a good start for understanding who will be accessing the database and what types of information they will need. Understanding the many users or actors of the system and what types of information they will require gives a good first look into how the database will grow and how quickly.

Activity diagrams are used to describe the flow of user activities in the system and how they interact with the database. There are many tagged values that can be captured on an activity diagram that can help designers understand the frequency of use. Timing of events on an activity can be captured with these tagged values and they can help to again clarify the frequency of accessing the database. The activity diagrams may not drill down onto the specific data that is being ac cessed, but they give a good high-level view of what data will be captured and how often as well as the activities that lead up to the access of the database.

Sequence diagrams are also used to build the database and application structures by uncovering the objects used in the application and database and turning them into classes and tables. The interaction between objects in the sequence diagrams shows how the objects communicate and through what methods . By understanding how the objects communicate and capturing information on the frequency, database designers can understand the acquisition of data and build indexes. For the deployment of the database, the database de signers use the sequence diagrams to understand the frequency of added data to estimate the size of the database and how quickly it will grow over time. Understanding the interactions between objects gives the database de signer not only a visual of what is going on between the objects but also the ability to model the frequency of the data access.

The class diagrams help the database designers build a logical design model by capturing the entities, attributes, and associations that are needed to de scribe the database structure, but they also provide knowledge on how to partition the data. Entities that are persistent generally become tables in the database, but they may be combined into other tables or split into multiple tables. By going back to the logical design model to understand the initial intent of the system, prior to denormalization for the database design, the database designers can understand how application elements or classes may communicate across each other and which data are intended to be accessed by which classes. By understanding the logical design, the database designers can build tablespaces that encompass a user's intent and file the data as a user would access it, rather than just from the abstract of how the database tables are created. Building partitions within a table gives the ability to store parts of the table's data on different drives. A partition may contain different types of data or data based on indexes so that you can store all of the data for customers with names from A to N in one partition and those from O to Z in another partition. Again, by understanding the intent of the system ”why it is built and the data that is intended to be stored in the database ”the database designers can make highly educated decisions rather than guesses.

With the use of the UML Profile for Database Design designed by Rational Software Corporation, the use of component and deployment diagrams and the artifacts that exist within those diagrams provides a great place to create the elements needed for physical database design, implementation, and deployment. The ability to visualize the physical database information is just one more reason that the UML is the way to design the entire database application from requirements through to the final application and database design. Through the use of modeling artifacts from requirements through to the deployment of the database in one language and modeling technique, rather than some in text, some graphically, and some most likely in code, the database designers can make decisions on the design of the database from one common set of artifacts and be precise in the design of the database architecture.

Putting It All Together

Building the database design starting with requirements and driving through to the completed database implementation is a difficult task, but modeling throughout the entire process can make it much easier to understand. Having all artifacts of the system contained in models and defined in documents for greater detail may seem to be a waste of time, but when you have completed the system and it fits directly with your customer's needs, you will understand that while the modeling process may have taken a little bit longer up front, it saved a lot of time in the end. Having the models for future requirements will help to assess the impacts of changes when the client company needs to up grade its systems or has realized what items it initially forgot .

The UML has the ability to create separate diagrams, for example, a diagram with the stereotype of <<Use Case>> that contains only elements specific to use cases. You can also break from that plane and not stereotype diagrams so you can include all artifacts needed in one place. Having a diagram that shows a use case and the classes and tables that are created from that use case is helpful for clarifying to both the developers and the end users that the correct information and understanding of the requirements have been met (Figure 8-1).

Figure 8-1. Use cases, classes, and tables on the same diagram

By creating tablespaces as model elements, you can visualize how tables relate to the tablespaces and where they will reside in the database. With the tables, tablespaces, schemas, and databases on the same diagrams it becomes quite easy to understand how the database is organized. 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. It is important to understand what data the database is going to contain, how it will be structured, and how much interaction users will have with the database. By having all of the information captured and designed from the beginning, the database designers can make intelligent decisions when designing the storage of the database.