The typical approach to moving into the actual modeling of the database is to use all of the classes that were already captured and understand how they will be come tables. At this point the classes that will be transformed into tables should have been marked with a tagged value of persistent. This tagged value means that the class requires data and that the data for this class persists in the database. Therefore, the database must contain the needed structures to support the class. Having already worked through the requirements and an understanding of what is being built and how to describe it from both a business and a technical sense, it is much easier to determine what tables to create, the data and descriptions of those tables, and how to construct them.
Although the database design team has been involved with the previous requirements gathering and modeling of the needed elements, it is now time to look at the model from strictly the database point of view. The database designers look at the needs of the database from a more physical view. It is not yet quite the time to look at specific database server requirements, but we begin to understand what would make this a good optimized data model. For example, do all of the tables have unique identifiers? Is referential integrity being en forced through key migration? Are there rules within the database, from the earlier requirements, that may cause a need for constraints and stored procedures? Employ corporate and group standards to ensure that the database model meets the rules of the organization.
Since we are using the UML, an understanding of how models are built in the UML and perhaps a tool that supports database design using the UML are very helpful at this point. You can use the UML and any tools that support the creation of stereotypes to begin this process, but it is always easier if you al ready have the stereotypes and database knowledge so that the tool can get out of your way and the database designers can just start working on the model. Knowledge of the entire UML itself is quite helpful at this point as well, allowing the modelers not only to build their database models but also to use the existing models to understand what has been done and described so that the modelers can continue to use the requirements and definitions for those requirements that have already been described.
When building a database model, it is beneficial not to concern yourself with the physical aspects of the database until you are sure that all of the requirements have been captured and modeled as database elements. For this reason, we do not cover the physical storage of the data here, saving example schemas, tablespaces, databases, and other items until the next chapter. This chapter focuses on how to build the database model using the UML without a focus on implementation. However, the database designers begin to think about the implementation with the creation of views to store data for better access, constraints to enforce rules that were uncovered during the earlier processes as well as during database modeling, indexes based on query patterns that may have been uncovered in sequence diagrams, and stored procedures and triggers to enforce rules that have been identified.