Howard Ong Principal Consultant Aurora Consulting Pty Ltd Abstract Like many Oracle developers, the author has endeared himself to Oracle Designer for many years. Ever since Oracle placed Designer on maintenance support (the equivalence of life support for a software package), Designer s faithful band of followers have been waiting for Oracle to introduce the next killer data modelling tool. The introduction of SQL Developer Data Modeler is a glimmer of light in a very long tunnel. This paper examines the features of Data Modeler and attempts to answer the all-important question: are we ready to turn off Designer s life support system? About The Author A frequent presenter at local and regional conferences, Howard has been a proficient user of database technology since 1991. In particular, Howard possesses in-depth experience in the planning and development of Business Intelligence and E-Business Applications. Harbouring a keen interest in the application of advanced database in these areas, Howard and his team have helped many organisations deploy BI and E-Business solutions using Oracle, Microsoft and IBM technology. Since 1997, Aurora Consulting has been delivering Data Warehouses and E-Business solutions to a wide variety of organisations including large government departments and ASX-listed companies. For more information on Howard or Aurora Consulting, visit http://www.aurora-consult.com.au or email info@aurora-consult.com.au. AUSOUG Conference 2009, Perth Page 1
[The follow evaluation is based on Oracle SQL Developer Data Modeler 2.0.0.57.0, first released 1 July 2009.] Introduction At the risk of sounding like an IT professional that has not kept up with the times, this author admits to loving the Oracle Designer product. And lets face it, even though 100% forms generation is consigned to the way of the dodos, Oracle Designer remained a great database design tool. Sadly, sentimentality does not go down well with the folks at Redwood Shore; and Oracle Designer has been on maintenance support (a.k.a. life support) for a number of years now. As a result, Oracle Designer has been left on the scrap heap and has not kept up with recent advancements in Oracle database technology. Many recently introduced Oracle database features such as materialised views, dimensions, directories, external tables, LOBs storage clauses are not supported by Oracle Designer. One of the most frustrating things of being a supporter of Oracle Designer is the lack of a replacement product from Oracle until now. Thus (drum roll ), it is great anticipation and hope and the author would like to introduce a new database designer tool from Oracle Oracle SQL Developer Data Modeler! (OK, first problem with the product, it has too long a name. In view of saving our precious forests, lets just call it Oracle Data Modeler from this point on.) The Basics Before looking any further, lets get the basics right and look at what Oracle Data Modeler is. Oracle Data Modeler is the closest thing to an Oracle Designer replacement product from Oracle in many years. Like Designer, it performs conceptual data modelling, it offers a full spectrum of data and database modelling capabilities: Entity relationship modelling Relational database design Multidimensional modeling Reverse engineering DDL generation It supports those recently introduced database features that Oracle Designer does not support. As an open-platform product, Oracle Data Modeler supports Oracle and non-oracle databases, as data sources (for reading data dictionary definition in reverse engineering operations) and target databases. The databases supported are Oracle (9i, 10g, 11g), Microsoft SQL Server (2000 and 2005), IBM DB2/390 and DB2 LUW (Linux, Unix and Windows) v7 and v8. In spite of that, the author doubts Oracle will win too many converts form the non-oracle user base, especially considering that it does not support SQL Server 2008. Like its SQL Developer cousin, Oracle Data Modeler runs on multiple platforms (Windows, Linux, Mac OS X). Oracle Data Modeler does not require a database repository and is hence simple to install. The design is stored in file system as XML files. Oracle Data Modeler may be downloaded at http://www.oracle.com/technology/software/products/sql/datamodeler.html. AUSOUG Conference 2009, Perth Page 2
Before you rush in to your nearest web browser to download the tool, lets now look at what Oracle Data Modeler is not: It is not Oracle Designer. The 2 key differentiations are: it does not generate applications (no big deal); and does not run on a database repository (a potential problem). It is not SQL Developer. Data Modeler is a stand alone product. However, like SQL Developer, it needs JDK6 (not JRE6) to run. JDK is required for SQL Developer because it needs the Java Debugger. Data Modeler does not need the debugger s feature but inherits the requirement for JDK probably because it was built using the same underlying code base as SQL Developer. It is not free! On the July 2009 price list, licence cost is $3602 per user, and costs $793 per user per year for support. If you are looking for a freebie, all is not lost, there exists a read-only viewer, which is free. The design steps involved in using Oracle Data Modeler is very similar to Oracle Designer, illustrated by the following diagram: Where Logical Model approximates Designer s Entity Relationship Diagram. Relational Model approximates Designer s Server Model. Physical Model approximates Designer s DB Admin. The screenshots below illustrate the steps involved in designing a simple database, including some preliminary setup steps. AUSOUG Conference 2009, Perth Page 3
Oracle Data Modeler Work Areas Creating Domains Creating Entities AUSOUG Conference 2009, Perth Page 4
Creating Attributes Creating Relations AUSOUG Conference 2009, Perth Page 5
Logical Model Forward Engineer to Relational Model Adding Prefix To Tables AUSOUG Conference 2009, Perth Page 6
Relational Model Applying Naming Standards AUSOUG Conference 2009, Perth Page 7
While you are able to apply naming standards to keys and constraints at the click of a mouse, for those who are used to Oracle Designer s naming standards, the result may not be what you expect. Some of the differences between the 2 naming standards are: Oracle Data Modeler s naming standards use the full table name rather than the abbreviated name (Designer s table aliases) in naming keys and constraints. This leads to rather long and sometimes illegal names (where it becomes longer than 30 characters). For performance reason, the author usually creates indexes corresponding to foreign keys columns. In Oracle Data Modeler, there is no longer an association between a foreign key and the index. As such, the Designer s naming standard of tab1_tab2_fk_i is no longer used. If you like to your new database to use the same naming standards you have been using; or you are simply not used to the new naming standards (like the author), you can manually name the objects. To this end, there exists a feature to configure Oracle Data Modeler such that its naming standards are not applied for the types of objects you have manually named. However, there is bug causing this feature not to work in the current release. Creating Triggers AUSOUG Conference 2009, Perth Page 8
Creating Tablespaces As in Designer, once created the tablespace may then be associated with tables and indexes. However, a current limitation exists where a primary key may not be associated with a tablespace unless the USING INDEX clause is used. AUSOUG Conference 2009, Perth Page 9
Creating Stored Procedures There are a number of serious limitations to the Stored Procedure capabilities of Data Modeler: Only procedures are supported. Functions and packages are not supported. Parameters are not supported. Creating Users, Roles and Privileges AUSOUG Conference 2009, Perth Page 10
AUSOUG Conference 2009, Perth Page 11
Generating DDL Unlike Designer, where DB Admin is used to store strictly implementation definitions, Oracle Data Modeler s physical models are used to store many (in the author s view) design definitions. Some of the commonly used objects stored in the physical model are: Triggers Synonyms Materialised Views Stored Procedures Dimensions Directories External Tables Tables Partitions Index Partitions Users, Roles & Privileges Tablespaces AUSOUG Conference 2009, Perth Page 12
Note that there is an additional steps involved in storing and retrieving the physical model. In other words, if you open a design and the physical model you created previously is not there, don t panic. The physical model is not automatically opened on opening a design and you have to open it separately. Data Modeler Reports To report on the database model, the following setup steps are needed: Create a Reporting Schema from Oracle Data Modeler. Install Data Modeler Reports onto SQL Developer. The Data Modeler reports is no more than a few simple scripts that display the data from the Reporting Schema. For someone that is used to Oracle Designer s repository reports, the author finds these Data Modeler reports very inadequate. AUSOUG Conference 2009, Perth Page 13
Oracle Data Modeler stores each model in a standard directory with the model name as directory name with an main header file called model_name.xml. Thus, unlike Designer, it does not use a database repository to enable concurrent access. To support concurrent development, Oracle recommends that you use a source code control tool such as Subversion to manage concurrent changes made by different users. Unfortunately, this does not work in practice as merging just minor changes from different users corrupt the model file. Importing From Oracle Database Source Schema: SQL> select object_type, object_name from user_objects 2 where object_type not like 'INDEX%' 3 and object_type not like '%PARTITION' 4 and object_name not like 'DR%' 5 and object_name not like 'MVIEW$%' 6 order by 1,2 7 / OBJECT_TYPE OBJECT_NAME ------------------- ---------------------------------------- DIMENSION CHANNELS_DIM CUSTOMERS_DIM PRODUCTS_DIM PROMOTIONS_DIM TIMES_DIM LOB MATERIALIZED VIEW TABLE SYS_LOB0000054721C00006$$ SYS_LOB0000054726C00002$$ CAL_MONTH_SALES_MV FWEEK_PSCAT_SALES_MV CAL_MONTH_SALES_MV CHANNELS COSTS COUNTRIES CUSTOMERS FWEEK_PSCAT_SALES_MV PRODUCTS PROMOTIONS SALES SALES_TRANSACTIONS_EXT SUPPLEMENTARY_DEMOGRAPHICS AUSOUG Conference 2009, Perth Page 14
TIMES VIEW PROFITS SQL> select table_name,count(*) from user_tab_partitions 2 group by table_name 3 / TABLE_NAME COUNT(*) ------------------------------ ---------- COSTS 28 SALES 28 SQL> select index_name,count(*) from user_ind_partitions 2 group by index_name 3 / INDEX_NAME COUNT(*) ------------------------------ ---------- SALES_CHANNEL_BIX 28 SALES_CUST_BIX 28 SALES_PROMO_BIX 28 SALES_PROD_BIX 28 SALES_TIME_BIX 28 COSTS_PROD_BIX 28 COSTS_TIME_BIX 28 Defining Database Connection AUSOUG Conference 2009, Perth Page 15
Selecting Import Objects AUSOUG Conference 2009, Perth Page 16
Some roles are pre-selected. These include the roles the user has been granted - CWM_USER, RESOURCE and SELECT_CATALOG_ROLE. AUSOUG Conference 2009, Perth Page 17
All tablespaces where schema objects reside are pre-selected. AUSOUG Conference 2009, Perth Page 18
Notice that standalone functions and packages are not available for import as they are not supported by Oracle Data Modeler. AUSOUG Conference 2009, Perth Page 19
Imported Data Model AUSOUG Conference 2009, Perth Page 20
Table and index partitions Triggers Dimensions AUSOUG Conference 2009, Perth Page 21
Directories External Tables Users, Roles and Object Privileges AUSOUG Conference 2009, Perth Page 22
Synonyms AUSOUG Conference 2009, Perth Page 23
Tablespaces A physical model is created with many new database object types incorporated, including the following: Tables Triggers Views Synonyms Materialised views (created under the Tables stub) Stored Procedures Dimensions Directories External tables Table partitions Users and roles Tablespaces However, the following are not imported: Index partitions (the stubs exist but are blank) Standalone functions and packages Storage clauses. Object privileges (the information screen exists but are not populated) AUSOUG Conference 2009, Perth Page 24
Importing From Oracle Designer Defining Database Connection Selection Import Objects AUSOUG Conference 2009, Perth Page 25
AUSOUG Conference 2009, Perth Page 26
Imported Data Model AUSOUG Conference 2009, Perth Page 27
The following are not imported: PLSQL, triggers, and implementation details (table implementations, view implementations, sequence implementations, PLSQL implementations, tablespaces, storage definitions, and so on). Data model diagrams are imported as Subviews. Only the content of the diagrams are imported, not the specific layout, as illustrated in the screenshots below. In fact, Oracle Data Modeler s ability to format diagrams are substantial inferior to that of Designer. AUSOUG Conference 2009, Perth Page 28
Importing From DDL Selecting DDL File For the import to work, Oracle Data Modeler expects all DDL commands in one mega script, i.e. Designer-style multi-scripts setup is not supported. Selection Physical Model AUSOUG Conference 2009, Perth Page 29
Previewing Import AUSOUG Conference 2009, Perth Page 30
Imported Data Model Limitations Note also that importing from DDL does not import data model diagrams (subviews) and domains. In one case, a foreign key of a large table was not imported. This bug does not occur when importing directly from Designer. Conclusion Having trial a number of key features of Oracle Data Modeler, the author would conclude that while it shows promises, it is currently not an adequate replacement product for Oracle Designer. Promisingly though, Oracle has incorporated a number of useful features that was not in the Oracle Designer product. In time to come, as the product matures and the bugs are ironed out, this glimmer of light in the tunnel will blossom into a fullfledge spotlight - Oracle Data Modeler would likely become the database designer tool of choice within the Oracle developer community of the future. AUSOUG Conference 2009, Perth Page 31
AUSOUG Conference 2009, Perth Page 32