You can waste away many hours laying out the elements on a diagram. Therefore, this aspect of modeling can be time consuming. However, a model serves as documentation and a communication device. Therefore, taking the time to make sure it is well annotated and clearly designed is important. Most of the controls for the models are on the context menu, allowing you to modify individual aspects of the diagram. The context menu changes depending on whether you have an object or line selected, or you're just clicking in the open space. You can also set general defaults using Tools | General Options | Diagram. In this section, we'll look at the various options available when working with the diagrams.

Formatting the elements

Before moving a relationship line, entity, or table, you can dramatically change the impact and readability of a large diagram just by changing the colors. This is readily demonstrated when importing from two or more schemas. Using the previous example where we imported from two schemas, open one of the subviews and select all of the tables. With the objects selected, invoke the Format Object dialog using the context menu:

If this is the first time you are adjusting the colors, the dialog does not display any colors as you open it. The colors used in the diagram are the default settings. Deselect Use Default Color and click on the Background and Border Color items to select and set the new color. When you are done, click on OK and note the changes applied to the subview. Switch to the main relational model to review the impact there. The color applied to the subview is also applied to the main model as shown. This is very useful when illustrating how tables in different schemas relate to each other. For example, take the HR and OE sample schema, all of the tables related to human resources are maintained in the HR schema, while those related to the order entry system are maintained in the OE schema. You may well have applications designed around the HR schema and others tied to the OE schema, but some may involve both. In the following relational model, the OE tables are now colored green, so we're able to identify them, but we can also see where the schemas link. We can see that a CUSTOMER may deal with one EMPLOYEE and has many ORDERS:

Selecting all of the tables in a model
Select any table and click on Select Neighbors from the context menu. Select All Zones, to select all of the tables. Use this instead of Ctrl+A, which selects all tables and all lines.

Changing the default format settings

Instead of changing individual items or even a set of items, you can change the default color for each of the element types displayed on a diagram. The Tools | General Options | Diagram | Format provides the ability to control the color of each of the elements displayed such as tables, views, and entities:

To edit any of the elements in the dialog, double-click on the object, or select the object and the edit icon. This allows you to adjust the color of the item and to format the font. You can use the font color to highlight mandatory, Unique, or Foreign Keys.

Setting general diagram properties

Use the same Tools | General Options | Diagram to set model properties,which include:

• Displaying the grid
• Controlling the background color of the diagram
• Controlling the Auto Route feature which is on by default

Set display properties for certain items on each of the models, including the control of:

• The diagram notation for the logical model, which supports the Barker and Bachman notations
• The display of the relationship names for either the logical or relational models
• The flow names for process models

For example, to display the relationship names on an Entity Relationship Diagram (as seen below), check the display property on the Tools | General Options | Model | Logical, and ensure that the Relation Cardinality properties for the relationships are also set.

Creating subviews and displays

Adding subviews and displays offers you alternative ways of laying out elements on a diagram and for working with subsets of items. You can create multiple subviews and displays for either logical or relational models, and remove them as easily, without impacting the main models.

Adding subviews to your design

You have already encountered a subview by importing from a number of schemas in the data dictionary. Subviews are not only a reflection of the different schemas in a design, but they can also represent any subset of elements in the design, allowing you to work with a smaller, more manageable set of elements.

You can create a subview from the object browser by selecting:

• The SubViews node and using the New SubView context menu. In this case, you have a new empty diagram that you can populate by dragging tables or entities (depending on the subview in question) onto the page.
• Any of the model tabs and then selecting the Create SubView menu. This creates a new and empty subview.
• An element or elements on an existing model and using the Create SubView from selected context menu on the diagram. In this case, the new subview will contain the tables or entities you selected:

The layout of the subview is not linked to the main model in any way. What is linked is how you format the items on the subview and any structural changes you make to the objects. You can continue to add new items to the subview by dragging them onto the surface from the object browser. When deleting items from the subview, you should choose whether the item is deleted:

• From the view (Delete View)
• From the complete design (Delete Object)

Adding displays

A display is an alternative view of a diagram, whether a main model or a subview, and is linked directly to that model. If you delete the model, the display is also deleted. Any items that you add or remove from displays are also automatically added or removed from the main model they are linked to.

To create a new display, select the tab of any model and select Create Display from the context menu. The new display created is, initially, a replica of the model you selected in both layout and items available. All additional displays are listed at the bottom of the model. In the following example, the HR subview has two displays created, as highlighted at the bottom of the screenshot, the main HR display and the new Display_1. The Create Display context menu is also illustrated:

Use the new display to change the layout of the model and to adjust the level of detail displayed on the diagram.

A second display of the same model is useful when you want to show more or less detail on a model. You can, for example, create a display which only displays the entity or table names. Right-click in the space on a diagram and select View Details | Names Only. We'll discuss how to layout the diagram elements later.

Creating a composite view

If you create a number of subviews, create a new diagram showing the composite models of each of these on a single layout. This serves as a useful reminder of the number of subviews or models you have by having a thumbnail of the various layouts. Alternatively, you can add a composite view of one subview and place it on another.

To create a composite view, select the model in the browser and drag it onto the diagram surface. You can drag any model onto any other diagram surface, except its own:

Once you have the composite folder displayed on the diagram, display the composite model within that folder by selecting Composite View from the context menu. If the model you want to view has a selection of displays, then you can also select the display you want to see within that composite.

The following screenshot shows the, subview, displaying the composite models of the HR subview, the main logical model, and both displays of the logical model:

Controlling the layout

When working with a large number of items in a model, it's important to keep the layout organized. A variety of tools to help with the process are explained in the following sections.

Adjusting the level of detail displayed

Change the amount of detail displayed in a table (or entity) using the View Details menu. It is invoked with a right-click on the white space of any diagram. The View Details menu has options for displaying:

• All Details
• Names Only
• Columns
• Datatype
• Keys

Adjusting the width and height across the model

If you have a large diagram and want to see how tables or entities relate to each other, you can create a more compact model using a display, without impacting the main model. This can be done by setting the details to display the name only and then resizing and repositioning the objects.

In the following screenshot, we have set the model to display only the name of the tables. Create a more compact diagram by resizing one of the tables to a more fitting set of dimensions, select the rest, and then resize them all to the same width and height:

Controlling alignment

Once you have positioned the items, align them to complete the model. Use the Edit menu with the required items for top and left alignment as shown in the following screenshot:

Resizing and alignment
The first item you select is the one that drives the position for left or top alignment, and the item that controls the width and height of all subsequent items selected.

Working with lines

A clear layout is fundamental to a clear diagram. This includes ensuring that lines do not cross or lie underneath tables. SQL Developer Data Modeler has an Auto Route feature that is on by default (seen in the following screenshot). This prevents you from manually moving any of the relationship lines yourself.

Take manual control of the lines by using a right-click on the white space of the diagram and deselecting Auto Route. You can also set the Auto Route option to off, by default, using the Tools | General Options | Diagram setting.

Once you have control of the lines, you can select any relationship line and use the context menu to:

• Add Elbow—to reroute a line around other shapes
• Remove Elbow
• Straighten Lines 

Managing lines with elbows

For lines that have elbows (angles), you can select any point on the line to move them and change the shape. Moving the line also moves the end points of the line. You cannot select and move the end points themselves. You can also select any of the elbows to change the angles within the lines:

Managing straight lines

Diagrams are neater if there are fewer lines crossing and more straight lines. Where possible, remove the elbows and straighten lines. There is an option to straighten lines by removing all elbows on the lines. Straighten Lines will create a horizontal straight line between two tables or entities next to each other, and a diagonal line between elements that are not adjacent. You can only move the endpoints on a straight line and not the entire line.

Moving a straight line
To select and move a straight line, add an elbow. Then, without bending the line, you can select and position it where you choose to without needing to move both endpoints.

Integration with Oracle SQL Developer

SQL Developer 2.1 includes the Data Modeler Viewer extension. This viewer provides users with the option of opening existing SQL Developer Data Modeler diagrams or creating models based on the database connection. To open the Data Modeler in SQL Developer, select Tools | Data Modeler. This opens the Logical and Relational model tabs. Once open, you can open any data model created in the Data Modeler. To review the details of the model in the navigator, select View | Data Modeler | Browser.

You can open any Data Modeler model in SQL Developer 2.1 by selecting File | Open Data Modeler Design. Once you have the model and the Data Modeler browser open, you can browse and review all of the model properties. The model and properties are all read-only:

Creating a new model

The Data Modeler Viewer extension to SQL Developer also allows you to create models of the tables, views, and constraints in the database connections you have access to. To create a new model, expand the database connection in the Connections navigator, and then select the tables you want to include on a diagram. Drag the selection on the relational model (as seen in the following screenshot). You can't save the model, but you can move the objects on the diagram to change the default layout.

Creating and running reports

An important aspect of building a data model is to run reports against the designs, to ascertain if there are:

• Tables without columns
• Entities without attributes
• Columns or attributes without data types set

SQL Developer and the SQL Developer Data Modeler work together to support this functionality. You can use the Data Modeler to create and save the design to the reporting repository, and then use SQL Developer to run the shipped reports against the saved design.

Setting up the reporting schema

Before you can export any designs to the reporting schema, you need to create a user which  will own the tables in the reporting repository. The repository is made up of 42 tables, with columns and associated indexes. You can use either the SQL Worksheet, or the Create User context menu on Other Users, to create a repository owner. Grant the user CONNECT and RESOURCE privileges.

Starting in SQL Developer Data Modeler, create and refine your data model designs. Once they are ready, select Files | Export | To Reporting Schema. This action invokes the Export to Reporting Schema dialog:

The first time you export your design, you'll need to create a connection to the new repository schema. Click on the Add button to invoke the New Database Connection dialog. The repository is built in an Oracle database, so the connection details here are for an Oracle connection. Once you have created the connection you can reuse it on subsequent exports. Select the new connection, and click on OK. The first time you perform the export, the tables for the repository are created in the repository schema. Subsequent exports write new records to the tables.

Having exported the design, open SQL Developer and select the View | Reports tab. Expand the Data Modeler Reports node. There are two categories of reports available, as shown in the following screenshot. These are Design Content and Design Rules:

By default, the latest report for each design is displayed in the report. In order to see all exports of the design, enter FALSE in the Enter Bind Values dialog when running the report, and then click on Apply:

Use the reports to verify the completeness of your design, or create additional reports to extract further detail about your models. In the following screenshot, we have run the Design Rules | Relational Model | Columns report to determine which columns have no data type set. The report also provides the tables these columns belong to:

Summary

In this article, you have had an insight into the features offered by SQL Developer Data Modeler.

The subject of data modeling is vast, and this article only introduced some of the many and varied features available in SQL Developer Data Modeler. This article introduced some of the utilities available in SQL Developer Data Modeler. You also learned about the integration points with SQL Developer and the Data Modeler Viewer in SQL Developer.

Oracle SQL Developer Data Modeler

SQL Developer Data Modeler provides users with a lightweight tool which provides application and database developers a quick and easy way of diagrammatically displaying their data structures, making changes, and submitting the new changes to update a schema. In this article, we will not attempt to teach data modeling (except to provide some generally accepted definitions). Instead, we will discuss how the product supports data modeling and a few of the features provided. There are a variety of books available on the subject, which describe and define modeling best practice.

Feature overview

The Data Modeler supports a number of graphical models and a selection of text-based models. The graphical models are:

• Logical—this is the entity relationship model or Entity Relationship Diagram (ERD), and comprises entities, attributes, and relationships.
• Relational—this is the schema or database model and is comprised of tables, columns, views, and constraints. In SQL Developer Data Modeler, these models are database independent, and need to be associated with the physical model to support database specific DDL.
• Data Types—this is the model that supports modeling SQL99 structured types and for viewing inheritance hierarchies. The data types modeled here are used in both the logical and relational models.
• Multidimensional models—these models support fact, dimension, and summary classifications for multi-dimensional models.
• Data Flow—these models support the definition of primitive, composite, and transformational tasks.

The following support these graphical models:

• Domains—these allow you to define and reuse a data type with optional constraints or allowable values. You can use domains in the Logical and Relational models.
• Physical—this model is associated with a relational model and defines the physical attributes for a specific database and version.
• Business Information—this allows you to model or document the business details that support a design.

Tying these graphical and textual models together are a variety of utilities, which include:

• Forward and reverse engineering between the Logical and Relational models
• Import from various databases
• Export, including DDL script generation, for various databases
• Design Rules for verifying standards and completeness
• Name templates, glossary, and abbreviation files for supporting naming standards

Integrated architecture

SQL Developer Data Modeler is made up of a number of layers, which have a tightly synchronized relationship. The Logical model is thought of as the core of the product, providing the starting point for any design, and feeding details into other models. The following diagram shows an illustration of how the models relate to each other:

The logical ERD provides the basis for one or more relational models, and each of these feeds into one or more physical models, which are in turn used for the DDL generation. You can create separate data types models and use the defined data type in either the logical or relational models. Both relational and logical models can have multiple subviews created, and each subview can have many displays created.

Getting started

SQL Developer Data Modeler is an independent product, and with the exception of the Data Modeler Viewer extension to SQL Developer 2.1, is not packaged with other Oracle tools. You can download it and install it in a directory of your choice, with no impact on other tools. To install, simply unzip the file.

Installing and setting up the environment

Getting started with SQL Developer Data Modeler is straightforward. Follow the links from the Data Modeler site on OTN, http://www.oracle.com/technology/products/database/datamodeler to the download location. You are offered a choice of files to download:

• For Microsoft Windows, a ZIP file with or without the JRE included
• For the Mac OS X, a ZIP file without the JRE included
• For Linux, a ZIP file without the JRE included

For any of these ZIP files, extract the file contents and run the datamodeler.exe, which is in the top-level /datamodeler folder, or in the /datamodeler/bin folder. For Linux, use the datamodeler.sh executable.

If the file you choose does not include a JRE, you will be prompted on startup for the location of your installed JRE. The minimum supported release is JRE 1.6 update 6.0.

Oracle clients and JDBC drivers

If you are designing and building a model from scratch, or have access to the DDL script file for importing models, then you do not need to have access to a database. However, if you want to import from a database, you'll need to create a database connection. In this case, there is no need for an Oracle client in your development environment because you can use the thin JDBC Driver to connect to the database. SQL Developer Data Modeler also supports the TNS alias. Therefore, if you have access to a tnsnames.ora file, or have other Oracle software installed in your environment, you can access the tnsnames file to make the database connection if and when required.

Creating your first models

The Data Modeler browser starts with empty Logical and Relational models. This allows you to start a new design and build a model from scratch, whether a logical model with entities and attributes, or a relational model with tables and columns. The Data Modeler also supports metadata to be imported from a variety of sources, which include:

• Importing metadata from:
  • DDL scripts
  • Data dictionary
• Importing from other modeling tools:
  • Oracle Designer
  • CA Erwin 4.x
• Importing other formats:
  • VAR file
  • XMLA (Microsoft, Hyperion)

The context menu displaying the choices available is shown in the following screenshot:

Once you have created and saved your models, you can open these or share them with colleagues. To open an existing model, use the menu:

• File | Open—browse to the location of the files, which then opens the full design with all of the saved models
• File | Recent Designs—opens the full design, with all of the saved models, with no need to first search for the location
• File | Import | Data Modeler Design—more granular, offering a choice of models saved in a set of models

Recent diagrams
Use File | Recent Diagrams to display a list of all diagrams you have recently worked on and saved. Using this approach saves you from needing to browse to the location of the stored files.

Importing from the Data Dictionary

There are many ways to start using the tool by just starting to draw any one of the model types mentioned.

In the screenshot shown earlier, we highlighted the File | Import | Data Dictionary option. Using this allows you to import from Oracle 9i, Oracle 10g, Oracle Database 11g, Microsoft SQL Server 2000 and 2005, and IBM DB2 LUW Versions 7 and 8.

Creating a database connection

Before you can import from any database, you need to create a database connection for each database you'll connect to. Once created, you'll see all of the schemas in the database and the objects you have access to.

Access the New Database Connection dialog from the File | Import wizard (seen in the following screenshot). If you have no connections, click on Add to create a new connection.

For a Basic connection, you need to provide the Hostname of the database server, the Port, and SID. The connection dialog also supports TNS alias and the advanced JDBC URL.

Before you can add connections for non-Oracle databases, you need to add the required JDBC drivers. To add these drivers, use Tools | General Options | Third Party JDBC Drivers.

Using the import wizard

Once you have a connection created, select the connection and continue using the dialog by clicking on Next. You can select more than one schema during import. In the example below, we have selected two schemas, which results in three diagrams, one central model with all of the imported tables and views, and two subviews. When importing, a separate subview is created for each schema you select and all of the imported objects are displayed in that schema (this is not the only role for subviews).

In the Import Wizard displayed, there is a set of checkboxes and buttons below the listed schemas. By selecting All Selected, the screens that follow will have all instances of all objects automatically selected. Depending on what you are planning to import, it is often easier to keep that deselected and then use the Select All button on each object type tab:

Once you have selected the schemas, you can select the individual objects. Tables and Views are placed on the central Relational model and onto the respective subviews for each schema. All other objects, such as Roles, Users, and TableSpaces, are maintained in the Physical model listed in the object browser.

A summary of objects to be imported is displayed and you are offered the choice of the model destination. The default destination is Relational_1. The choice given here is needed for second or any subsequent imports. For these you need to decide whether you'll want to merge the objects into an existing model or create a new model.

To create the initial model, complete the dialog and select Finish. Each time you import a set of database objects, a log file of the completed activity is created, which tallys the number of statements and errors. It is worth saving the log files to use for troubleshooting later.

Importing multiple schemas from the Data Dictionary creates a central Relational model and a subview for each of the schemas imported.

Reviewing the results

Once the import is complete, the main Relational diagram opens:

The previous screenshot shows a few of the tables imported into the Relational model. To see the initial subviews created for each schema created, expand the Relational Models node and then the SubViews node. Right-click on one of the schema subviews listed and select Show Diagram.

In the following screenshot, we have opened the HR subview and are preparing to open the OE subview:

Saving designs

As you work, it is wise to save the design you are working on. It is prudent, in case something goes wrong, and necessary if you are going to close and reopen the tool later. Initially, a design is untitled. You can change this by saving the design. Once saved, the new name appears in the browser, and a set of folders and XML files are saved on your file system:

When you save a design, a folder and a file of the same name are created. The previous screenshot shows Windows Explorer with a folder of a saved design. Here, the top-level folder is called MyFirstModel, as is the top-level XML file. It is this top-level file that you select when opening a design. All of the files are XML and can be read. Do not edit these as doing so can corrupt your design.