SQL Developer Data Modeler: A Top-Down Product Overview

Transcription

1 SQL Developer Data Modeler: A Top-Down Product Overview Sue Harper Oracle United Kingdom Keywords: SQL Developer Data Modeler, ERD, DDL Generation, model, capture, design Introduction Oracle SQL Developer Data Modeler is a graphical data modeling tool for creating, browsing and editing data models, including logical, relational, physical, multi-dimensional, and data type models. It supports forward and reverse engineering from Oracle Database, Microsoft SQL Server and IBM DB2 databases and the generation of DDL scripts for these databases. SQL Developer Data Modeler offers features and utilities that enhance the data modeling experience, improve productivity and promote the use of standards. SQL Developer Data Modeler is designed for a broad spectrum of database developers; from business architects to DBAs and from database to application developers, serving as a powerful communication tool between developers and business users. In this article we review the main modelers and features in SQL Developer Data Modeler 2.0 starting with the logical model and progressing through the features to the final DDL script. Often called the top-down approach, this is not the only flow of work through the product, as indeed, users can start by importing a data model and reverse engineering the objects to create an initial diagram and progressing from there. We will refer to various methods of creating models and updating the database using the product. Integrated Models SQL Developer Data Modeler provides facilities to build sets of related and integrated models. Many consider the core of SQL Developer Data Modeler to be the logical model. It is this logical model that provides a true implementation-independent view of enterprise information. Using the logical model, often referred to as the Entity Relational Model (ERD), you can engineer relational models or multidimensional models. The ERD is also ultimately the source of many different physical implementations. A logical model or a part of it (subject area or sub view), can be transformed to one or more relational models. Each relational model can have an unlimited number of physical implementations in the form of physical models (referred to as RDBMS Sites in SQL Developer Data Modeler), with each physical model based on a supported database. Logical Models The logical model (or ERD) in SQL Developer Data Modeler includes standard logical modeling facilities, such as drawing entities and relationships. It also supports the choice of Barker or Bachman notations. The diagram itself provides for box-in-box representation for the display of the super-type and sub-type hierarchy of entities and you can easily create and display arcs, for the support of exclusive relationships. The image below provides an example of a logical model using the Barker notation and the box-in-box representation of super-types and sub-types.

2 Figure 1: SQL Developer Data Modeler Logical Model Relational Models The SQL Developer Data Modeler relational model is an intermediate model between the logical model and the physical models. Some refer to this as the server diagram or data model as it is made up of tables, columns and constraints and is a result of the transformation from the logical model. The relational model supports relational design decisions independent of the constraints of the target physical platform(s), which means that you can use one design for any of the supported target databases. All many-to-many relationships and all super-type/sub-types entity hierarchies are resolved during forward engineering (transformation) of the logical model to a relational model. You can apply naming standardization to the models during the transformation, by applying a glossary of terms. Physical Models It is the physical model that allows you to add implementation-specific detail. Here you add structure and definition to the objects, such as adding partitions and sub-partition detail, or adding elements not exposed on a diagram, such as sequences, tablespaces and roles. There is no diagram associated with the physical model, so all changes and updates are through the property dialogs which you can invoke from the browser. Data Type and Structured Type Models The Data Types model is independent of each of the above models, allowing you to create and visualize structured types and the inheritance hierarchies of structured types, defining distinct and collection (array) types on a model and then use these in either the logical or relational models. You can also add physical detail to these data types through the physical model. Creating New Models

3 On opening SQL Developer Data Modeler, two empty model tabs, the logical and relational models, are automatically opened. To start creating a new model, use the toolbar and click on the appropriate button, for example the entity or table button, and then click on the model. Each action invokes the associated dialog, allowing you to create or update the elements on the diagram. Once you have created the logical model you can forward engineer this to a relational model. The Data Modeler also supports the reverse process. Importing Existing Models You can also import existing logical models, multi-dimensional, or relational models instead of creating them from scratch. You can create relational models by importing script files (DDL) or by importing directly from the data dictionary. SQL Developer Data Modeler can also import directly from the Oracle Designer repository or import CA ERwin Data Modeler export files. Extensive and wizard-led engineering capabilities allow you to re-engineer a relational model to a logical model or to engineer a logical model to one or more relational models, where both models can be kept synchronized. Importing from the Data Dictionary While not necessarily a part of the top-down approach, you can also create models by importing or reverse engineering directly from the database. SQL Developer Data Modeler provides selection lists for all supported objects and with it the ability to filter out secondary tables. While importing, you can import the objects from one or more schemas. The Data Modeler creates a single diagram for all tables and views and a separate subview for each schema imported. Generating Scripts Once you have created the models and updated the physical properties for the objects, you can generate the DDL scripts. SQL Developer Data Modeler supports generation of DDL scripts for Oracle, DB2 and SQL Server. The DDL generation supports a wide variety of features, by allowing you to generate interactive DDL scripts, add additional code into the scripts, and even name substitution facilities to ease database migration tasks. For example, you can have the same set of database objects exist in different databases (test, development, production environments, etc.) but with different naming templates. Updating the Database through DDL Scripts Once you have established your data model and have generated and executed the DDL, you may also want to update the database using the Data Modeler. SQL Developer Data Modeler enables safe and effective through the generated DDL scripts. To update an existing database design, you need to determine whether it is the database or the model which is to be the point of truth. By this we mean that you might want to use the database to update your model. This is easily done by importing the objects in the database to the same data model and allowing the tool to update the diagram. A Compare Model dialog allows you do select the objects you want updated. If, on the other hand, you want the model to update the database, you need to create the alter database DDL scripts. This is also achieved through the import menu, by directing the import to Swap Target Model. In the following image, the model, with details listed on the left, includes the CATEGORIES table, which does not appear in the selected data dictionary schema import, displayed on the right. In addition, the process reveals that there are additional tables, such as the EMP and DEPT tables, in the schema selection, which are not on the model. In both cases, the user has the choice of including the objects in the DDL. The review and save the DDL that updates the database, click DDL Preview.

4 Figure 2: SQL Developer Data Modeler: Compare Model Dialog Formatting, Sub views and Displays The easiest way of managing a large set of objects is to split the model into subject areas. SQL Developer Data Modeler refers to these subject areas as subviews. Typically, a subview is a group of related objects on a diagram and any changes you make to the object in the subview are reflected in the main model. On importing multiple schemas, a single relational model is created for all the objects and a separate subview is automatically created per database. Subviews make it easier to maintain larger models. You can also control colors, fonts and the dimensions of the objects on a model. Diagram Linking In addition to standard diagram drawing capabilities, SQL Developer Data Modeler supports diagram nesting or linking. For example, a data flow diagram can be visually nested in a relational. Nested diagrams can be visualized as icons or in a composite view. If a nested diagram has more than one display, one of them can be selected to represent the diagram. Naming Standards SQL Developer Data Modeler supports naming standard glossaries, and also provides flexible and unrestricted naming rules through naming templates. These template or name patterns mean that you

5 can define naming rules for table elements. You can create name patterns for indexes and constraints (including Primary Key and Unique key) using a combination of predefined variables, e.g. {table}, {child}, {parent}, {column}, {seq_nr}, {model} and alphanumeric constants and combining these, optionally with the SUBSTR function to restrict the total length of the word. Once created these templates can be applied to single objects or to a complete model, thus allowing you to standardize or change the naming convention for a full data model. Design Rules SQL Developer Data Modeler provides a set of predefined Design Rules that can be applied at any stage of the design process. Design Rules help you to identify gaps or inconsistencies in the design, from as simple a task as finding all tables without columns defined, to finding columns without domains. Using the Reporting Repository SQL Developer Data Modeler supports a reporting repository, which means that you can export your designs to a separate Oracle schema and then run SQL queries against the schema to gather details of the designs. A set of predefined reports are available in Oracle SQL Developer, thus providing an initial set of reports which you can run against the schema and also providing a starting point for creating your own reports. Summary In this paper, we have illustrated many of the key features of Oracle SQL Developer Data Modeler 2.0. Oracle SQL Developer Data Modeler provides a toolset to help anyone involved in the data modeling and data design process. It supports logical or conceptual modeling, relational database modeling, detailed physical implementation details and DDL script generation. The product supports a top-down modelling approach, allowing users to start with a blank logical model and then to design database agnostic models which are then engineered to relational models, with additional physical properties added before the generation of the DDL scripts. Additionally, users can import the definition of the schema from a database data dictionary to create models, update these and then update the data dictionary in turn. For more detail and to watch online demonstrations, work through online tutorials and to download the product, visit Contact address: Sue Harper Oracle Corporation 520 Oracle Parkway Reading Berkshire RG6 1RA Phone: +44(0) Fax: +44(0) sue.harper@oracle.com