192 CHAPTER 9 CASE Tools for Logical Database Design The low-end tools (selling for less than US$100 or available as open source) provide the most basic functionality for ER modeling. The higher end products provide the kinds of support needed for serious project design, such as: • Complete round trip engineering • UML design • Schema evolution; change management • Reverse engineering of existing systems • Team support, allowing multiple people to work on the same project concurrently • Integration with Eclipse and .NET and other tooling products • Component and convention reuse (being able to reuse naming standard, domain, and logical models over multiple design projects) • Reusable assets (e.g., extensibility, template) • Reporting 9.3 The Basics All of the products in question provide strong, easy to use functions for both data modeling and database design. All of these products provide the ability to graphically represent ER relationships. These tools also provide transformation processes to map from an ER model into an SQL design (DDL), using the transformation types described earlier in Chapter 5: • Transform each entity into a table containing the key and nonkey attributes of the entity • Transform every many-to-many binary or binary recursive rela- tionship into a relationship table with the keys of the entities and the attributes of the relationship • Transform every ternary or higher-level n-ary relationship into a relationship table Similarly these tools produce the transformation table types described in Chapter 5: Teorey.book Page 192 Saturday, July 16, 2005 12:57 PM 9.3 The Basics 193 • An entity table with the same information content as the original entity • An entity table with the embedded foreign key of the parent entity • A relationship table with the foreign keys of all the entities in the relationship Chapter 5 also described rules for null transformations that must apply, and the CASE tools typically enforce these. These CASE tools also help with the modeling of normal forms and denormalization to develop a true physical schema for your database, as described in Chapter 5. The tools provide graphical interfaces for physi- cal database design as well as basic modeling of uniqueness, constraints, and indexes. Figure 9.3 shows an example of the IBM Rational Data Architect’s GUI for modeling ERs. Figure 9.4 shows a similar snapshot of the interface for Computer Associate’s AllFusion ERwin Data Modeler. Figure 9.3 Rational Data Architect ER modeling (courtesy IBM Rational Division) Teorey.book Page 193 Saturday, July 16, 2005 12:57 PM 194 CHAPTER 9 CASE Tools for Logical Database Design After creating an ER model, the CASE tools enable easy modification of the model and its attributes through graphical interfaces. An example is shown below in Figure 9.5 with IBM’s Rational Data Architect, illus- trating attribute editing. Of these CASE tools, Rational Data Architect has perhaps the most useful UML modeling function for data modeling and design. Its predecessor, Rational Rose Data Modeler, was the indus- try’s first UML-based data modeler, and IBM has continued its leadership in this area with Rational Data Architect. UML provides a somewhat richer notation than information engineering (IE) entity-relationship diagram (ERD) notation, particularly for conceptual and logical data modeling. However, the IE-ERD notation is older and more commonly used. One of the nice aspects of Rational Data Architect is the ability to work with either UML or IE notation. Figure 9.6 shows the AllFusion ERwin screen for defining the cardi- nality of entity relationships. It is worth noting that many relationships do not need to enter this dialog at all. Figure 9.4 AllFusion ERwin Data Modeler ER modeling (picture from Computer Asso- ciates, http://agendas.ca.com/Agendas/Presentations/AFM54PN.pdf) Teorey.book Page 194 Saturday, July 16, 2005 12:57 PM 9.3 The Basics 195 Figure 9.5 Property editing with IBM Rational Data Architect (courtesy IBM Rational Division) Figure 9.6 Specifying one-to-many relationships with ERwin (courtesy Computer Associates) Teorey.book Page 195 Saturday, July 16, 2005 12:57 PM 196 CHAPTER 9 CASE Tools for Logical Database Design 9.4 Generating a Database from a Design To really take your design to the next level (i.e., a practical level) you will need a good design tool that can interact with your specific database product to actually create the Data Definition Language (DDL) and asso- ciated scripts or commands to create and modify the basic database for you. For instance, using the example of Chapter 7, we have modeled an ER model containing the sales relationships shown in Table 9.1. The CASE tools will automatically generate the required scripts, including the DDL specification to create the actual database, and will provide you with an option to apply those changes to an actual data- base, as follows: create table customer (cust_no char(6), job_title varchar(256), primary key (cust_no), foreign key (job_title) references job on delete set null on update cascade); create table job (job_title varchar(256), primary key (job_title)); create table order (order_no char(9), cust_no char(6) not null, primary key (order_no), foreign key (cust_no) references customer on delete cascade on update cascade); Table 9.1 ER Model Containing Sales Relationships ER Construct FDs Customer(many): Job(one) cust-no -> job-title Order(many): Customer(one) order-no -> cust-no Salesperson(many): Department(one) sales-name -> dept-no Item(many): Department(one) item-no -> dept-no Order(many): Item(many): Salesperson(one) order-no,item-no->sales-name Order(many): Department(many): Salesperson(one) order-no,dept-no-> sales-name Teorey.book Page 196 Saturday, July 16, 2005 12:57 PM . CASE Tools for Logical Database Design 9.4 Generating a Database from a Design To really take your design to the next level (i.e., a practical level) you will need a good design tool that can interact. the modeling of normal forms and denormalization to develop a true physical schema for your database, as described in Chapter 5. The tools provide graphical interfaces for physi- cal database design. Job(one) cust-no -> job-title Order(many): Customer(one) order-no -> cust-no Salesperson(many): Department(one) sales-name -> dept-no Item(many): Department(one) item-no -> dept-no Order(many):