The contents of this blog are mostly about development tools; early postings are all about Oracle SQL Developer and SQL Developer Data Modeler written as product manager for these products. There are also the occasional forays into travel, conferences and a mention or two of the Delhi missions I have done.
From October 2011, the entries will still have a SQL, PL/SQL and application development flavor using new technologies, as I am no longer with Oracle. Why not stay and read awhile?

Followers

Subscribe To

Follow by Email

My Other Blogs

About Me

30 July 2009

The Data Modeler supports Partitions

So the snag with a new product is to try to show all the features in the product to everyone as quickly as possible. I'm working on the online demos and training internal teams and getting the message out in general, but it's not fast enough. I'm looking forward to the day when you all start blogging about the product. Until that happens I'm afraid we're going to be dipping and diving all over the place. Just wait until SQL Developer 2.1 comes out and this blog becomes a mix and match!

We've recently had the question asking when we'll start support for partitions. The answer is right now. The product already does.

You need to understand the difference between the relational table definition, and the physical definition.

When you start creating the relational model, you create the tables that make up the diagram. The details are listed under tables under the relational node, as shown in this first image. (Click the image to see a full screen shot)

Invoking the properties here for the table, provides a database independent view of the table. So you can specify columns and datatypes and make use of domains at this point. What you can't do is specify the schema details or the other physical properties, like the tablespaces or partitions. This is because not all databases support the same set of physical properties.

The second screen shot shows the property dialog for the table in the relational model. Here you can add columns, set primary or foreign key properties, the datatypes and domains. There are entry point for indexes and a variety of additional features. But you do not set any database specific implementation details.

If you expand the physical model under the main relational model, (select Open from the context menu and select the database you want to support) and then expand the node. This is also shown in the first image above. Now you can view or add partitioning details.

Below are two illustrations, one showing the partition order in the Sales table, which is partitioned by range.

The last of the screen shots displays another partitioned table. The illustration here shows the drop list to show the types of partitioning supported.

The mantra is: The logical model is central, if you like is the core of the product. Each logical model supports one or more relational models. These visual models are database independent. Each relational model supports one or more physical models.

What the next demo to come out later this week, where we import for the data dictionary. That demonstration shows the multiple physical database support.