Logical database design with Unified Modeling Language
UML modeling is based on object-oriented programming principles. UML defines a standard set of modeling diagrams for all stages of developing a software system.
This information describes the entity-relationship model of database design. Another model that you can use is Unified Modeling Language (UML). The Object Management Group is a consortium that created the UML standard. This topic provides a brief overview of UML.
The basic difference between the entity-relationship model and the UML model is that, instead of designing entities as this information illustrates, you model objects. Conceptually, UML diagrams are like the blueprints for the design of a software development project.
Some examples of UML diagrams are listed below:
- Class
- Identify high-level entities, known as classes. A class describes a set of objects that have the same attributes. A class diagram shows the relationships between classes.
- Use case
- Presents a high-level view of a system from the user's perspective. A use case diagram defines the interactions between users and applications or between applications. These diagrams graphically depict system behavior. You can work with use-case diagrams to capture system requirements, learn how the system works, and specify system behavior.
- Activity
- Models the workflow of a business process, typically by defining rules for the sequence of activities in the process. For example, an accounting company can use activity diagrams to model financial transactions.
- Interaction
- Shows the required sequence of interactions between objects. Interaction
diagrams can include sequence diagrams and collaboration diagrams.
- Sequence diagrams show object interactions in a time-based sequence that establishes the roles of objects and helps determine class responsibilities and interfaces.
- Collaboration diagrams show associations between objects that define the sequence of messages that implement an operation or a transaction.
- Component
- Shows the dependency relationships between components, such as main programs, and subprograms.
Many available tools from the WebSphere® and Rational® product families ease the task of creating a UML model. Developers can graphically represent the architecture of a database and how it interacts with applications using the following UML modeling tools:
- WebSphere Business Integration Workbench, which provides a UML modeler for creating standard UML diagrams.
- A WebSphere Application Server Developer Tools for Eclipse plug-in for modeling Java™ and web services applications and for mapping the UML model to the entity-relationship model.
- Rational Rose® Data Modeler, which provides a modeling environment that connects database designers who use entity-relationship modeling with developers of OO applications.
- Rational Rapid Developer, an end-to-end modeler and code generator that provides an environment for rapid design, integration, construction, and deployment of web, wireless, and portal-based business applications.
- IBM® Rational Data Architect (RDA) has rich functionality that gives data professionals the ability to design a relational or federated database, and perform impact analysis across models.
Similarities exist between components of the entity-relationship model and UML diagrams. For example, the class structure corresponds closely to the entity structure.
Using the modeling tool Rational Rose Data Modeler, developers use a specific type of diagram for each type of development model:
- Business models—Use case diagram, activity diagram, sequence diagram
- Logical data models or application models—Class diagram
- Physical data models—Data model diagram
The logical data model provides an overall view of the captured business requirements as they pertain to data entities. The data model diagram graphically represents the physical data model. The physical data model uses the logical data model's captured requirements, and applies them to specific DBMS languages. Physical data models also capture the lower-level detail of a DBMS database.
Database designers can customize the data model diagram from other UML diagrams, which enables them to work with concepts and terminology, such as columns, tables, and relationships, with which they are already familiar. Developers can also transform a logical data model into to a physical data model.
Because the data model diagram includes diagrams for modeling an entire system, it enables database designers, application developers, and other development team members to share and track business requirements throughout the development process. For example, database designers can capture information, such as constraints, triggers, and indexes directly on the UML diagram. Developers can also transfer between object and data models and use basic transformation types such as many-to-many relationships.