Previous Section Next Section

The Approach

If you haven't already, at this point in the process it is time to choose a specific DBMS vendor. Generally this has been done in advance of building the database design model or at least during that process so that the design can include elements that are useful for the particular server. It is important to have the DBMS chosen by the time deployment is needed so that you have somewhere to deploy the database and so the database design can continue to include the storage.

The database designers work with the database administrators to understand the storage needed for the data. They coordinate their efforts to include the hardware in servers and drives necessary for the data as well as the best way to organize the data into tablespaces and the container to hold it. Tablespaces provide a good way to organize the data to make data easier to find, to prevent data from overloading the server or drives, and to keep similar data together.

As specified in the UML Profile for Database Design, the storage of the data is modeled primarily with components. Using the components to model the database storage for tablespaces, schemas, and databases, the database designers can visualize how the data is to be stored and quickly get an understanding of what data resides where and how much. In the initial steps of modeling the storage, modeling the schema and database may not be so important, but having the tables and tablespaces is. Getting a good representation of how the tables are proportioned across tablespaces and which tables are partitioned into multiple tablespaces is very important for ensuring enough storage room for the data now and as it will grow over the life of the database and application.

Partitioning the Database Tables

Some but not all of the DBMSs available support the ability to partition data within tables across multiple tablespaces or storage units. Some of the databases even allow for partitioning to occur on indexes, including the ability to set values for the index and have different parts partitioned on different tablespaces. An example of partitioning an index is to have an index that includes first and last names. You may partition the index into three parts, for example, one tablespace for names that are from A to G, another from H to R, and the last from S to Z.

Modeling the Schema

A schema is the structure of the database. A database can be made up of multiple schemas. The schema as it describes the database is made up of tables and columns. Since a schema is composed of multiple tables and one or more schemas is used to make up the entire database, it is therefore quite helpful to visualize how tables are related to schemas. Sometimes a diagram becomes quite difficult to read with the many relationship lines it contains, so sometimes it makes sense to leave the relationships off of the diagram but still capture them inside the model as metadata. The schema association to tables can be made late in the game, and often a database is composed of only one schema. It is much more important to build the tablespaces and ensure that they are built properly and allow for proper design.

Modeling the Database

The database itself is modeled as a component, but it is most likely the least important modeling element discussed. When modeling the database, it is comprised of many tables, columns, relationships, tablespaces, schemas, and more, so it is important to understand the database structure and the properties specific to that DBMS as well. The database is modeled as one of the components of the database and is related to tablespaces and schemas through dependency relationships. The database is modeled this way because a database is dependent on the tables that appear in it and on the schema that makes up the database. It does not make much sense to have each individual table have a dependency to the database, and since each table must reside in at least one or more tablespaces, the tablespaces make up the database; therefore, the database has a dependency on the tablespaces. The tablespaces already have a dependency on the tables so, by default, the database will be dependent on the tables as well. As with any modeling element, just because they are captured in metadata does not mean everything must be shown on a particular diagram; some information can be left off for visual purposes. In the UML, a cylinder icon (Figure 8-4) makes it easier to visualize a database on a diagram.

Figure 8-4. Database shown as a cylinder icon
Previous Section Next Section