- Exam topics that this chapter covers
- Logical database design with Unified Modeling Language
- Physical database design
- For more information
- Practice exam questions
- Answers to practice exam questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
Logical database design with Unified Modeling Language
This chapter 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 section provides a brief overview of UML. )
UML modeling is based on object-oriented programming principals. The basic difference between the entity-relationship model and the UML model is that, instead of designing entities as this chapter illustrates, you model objects. UML defines a standard set of modeling diagrams for all stages of developing a software system. Conceptually, UML diagrams are like the blueprints for the design of a software development project.
Some examples of UML diagrams are listed below:
-
Class: Identifies 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 Studio Application Developer 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 using 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.
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 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 applies the logical data model's captured requirements 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 allows 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 a physical data model.
Because the data model diagram includes diagrams for modeling an entire system, it allows database designers, application developers, and other development team members to share and track business requirements throughout development. 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.