The UML Differs from Traditional Database Modeling

Traditional database modeling promotes the basic theory that the database is the backbone of the system and everything revolves around that database. Although it is true that much ”if not most ”of the important information of the organization lives within the database, the database cannot stand on its own, and there are many other things that make up the company and its information. Without the applications to open the database to employees , there would be no accessible data. Without customers and transactions, there would be no information for the database. Without a business for which to build the database, there would be no reason to have a database. For these and many other reasons, the database must exist together with the rest of the organization and must be considered just one piece of the puzzle that must coexist with all the others.

The previous statement may seem obvious, but it is not evidenced in many of the companies we have worked in and visited. The database team often works on its own without open doors of communication. The information it captures is based on the database the team members are building and not the entire system that is needed. The blame should not be put onto the database team, though; the tools and methodologies that support the different types of design have led the database team down this road, and most people have not yet begun to move outside of the box into which they have been put. Using the most commonly available tools and the most prevalent methodologies, organizations have chosen to split the teams involved in requirements definition, development, and database management, enforcing the barriers and making communication difficult.

Bringing in the UML enables a common language for all teams involved and starts to break down those walls, reuniting people into one development team. Traditional database modeling concerns itself mainly with the database. The database is very important, and you must concentrate on your subject matter area. The problem begins when people focus so hard on their subject matter areas that they don't think outside of that subject and don't even communicate beyond their walls. Bringing a common language like the UML into the mix doesn't require you to do your database modeling differently ”it just means that the database modeling that you are doing today must expand outside of just the database structures and become a part of the entire analysis and design process.

In the process that we follow throughout this book, we explore the various parts of the development process, focusing on the job of the database analyst and designer. Using the UML doesn't inhibit the way that you traditionally de sign the database, although the notations may look a little different compared with the familiar old ones. When designing the database with the UML, you still have tables, columns , triggers, constraints, and the other elements that you generally use when modeling and designing a database. They just may be described a little bit differently and will definitely be more easily communicated to the rest of the teams involved with the development process.

The UML gives you the ability to model, in a single language, the business, application, database, and architecture of the systems. By having one single language, everybody involved can communicate their thoughts, ideas, and requirements. As described earlier, you can use the parts of the UML that are pertinent to your job and not be left out when other teams do their tasks . Also, by using the UML, you can always go back in the process to update information and include new information that may be discovered or required later.

In this book, we cover the different ways to model during the life cycle of database design and how the different teams can work together to accomplish common goals through modeling. By having all teams working together to understand and define the business, uncover needed changes, prioritize those changes, and model the business, they can all understand the job ahead. This will also help them recognize changes to the requirements as the project proceeds to ensure that each team takes advantage of changes made by others and to successfully use the changes that are made.