Database Modeling & Design Fourth Edition- P42 pot

The higher end products provide the kinds of support needed for serious project design, such as: project concurrently standard, domain, and logical models over multiple design projects 9

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:

project concurrently

standard, domain, and logical models over multiple design projects)

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:

attributes of the entity

rela-tionship into a relarela-tionship table with the keys of the entities and the attributes of the relationship

relationship table Similarly these tools produce the transformation table types described in Chapter 5:

• An entity table with the same information content as the original entity

entity

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)

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)

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)

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

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