It’s worth a few moments to get your bearings when using a new program. Or maybe you’ve been using SQL Developer Data Modeler for awhile now, and just haven’t taken the time to understand how designs, models, and diagrams are handled.
This short post will fill in a few gaps and increase your comfort level with the tool, so please bear with me!
Organization and Navigation
Navigation is handled by the Browser. The Browser displays your designs, models, and diagrams in a ‘tree.’
When you open a design, it will prompt you to select one of more relational models. Those models will be opened, added to the tree, and the diagrams will be displayed.
SQL Developer Data Modeler’s Logical Model
Every relational model has a logical model, even if that logical model is null or empty. Wait, let me clarify that point further. Every design has a single logical model. So if you have 2 or more relational models, they ‘share’ a single logical model.
The diagrams are opened by default. If you want less clutter in your desktop, you can ‘hide’ the logical model and save the design. When you open the design again, the logical model diagram will not be shown. Another reason to ‘hide’ your logical models is the size of its diagram. If it has many entities, it can take a long time draw this on opening the design. ‘Hide’ it, and only open it on demand.
Your relational model can have zero, one, or many physical models. Physical models do not have diagrams.
It occurs to me, maybe a diagram will help describe how designs are organized?

An entity of the Logical Type contains one or more of the Relational Type. And entity of the Relational Type contains zero, one or more of the Physical type.
This diagram uses the Barker Notation (although we also support Bachman and Information Engineering notations.) Thanks to @KentGraziano for the help getting this right. If you don’t have your own Oracle ACE Director available, try EntityModelingOrg for a quick primer on one-to-one, one-to-many, etc. relationships and how they’re represented in diagram form.
Opening, Saving, Showing Designs
As you open a design, it’s added to the tree. You can see in my first screenshot that I have 5 designs open. If I want to save a change to a design, the easiest way is to right-click on the design in the tree and select ‘Save Design.’ Otherwise, if you use the File > Save dialog, SQL Developer Data Modeler will prompt you for a design.
You can hide or show diagrams by right-clicking on the model. Hiding it doesn’t ‘close’ it – it just saves you space in your desktop.
Another fun fact: some of the application preferences are tied to specific designs. For example, if I create a new ‘Site’, it will prompt me for a design first. That’s right, you can have sites, domains, and other ‘preference’ or ‘setting’ level items tied to a particular design.
What’s a site? Read this to learn more about managing different physical implementations of your relational models.
In the case of sites, you can create a ‘global’ sites listing which is stored in an external file – a file that is external to the design.
Sharing Your Designs
The design is defined by a single xml file having a .dmd file extension. This file contains the listing of the many xml files used in the design. So when you want to email your design to someone else, you need the dmd file AND the directory containing all the XML files.
What About Datatype, Process, and Multidimensional Models?
I think that’s enough content for one post! We’ll pick this subject up at a future date





Twitter
RSS
GooglePlus
Facebook
Feb 21, 2013 @ 15:45:43
So to your point about the logical model: Did you really mean that One Relational Model Must have One or More Physical Models and that One Physical Model May have One and Only One Relational Models? Isn’t possible to have a Relational Model w/o a Physical?
One the mandatory Logical/Relational question, if a Logical Model is empty (NULL) does it really exist?
Feb 21, 2013 @ 16:54:06
I meant to say that a relational model will always have 1 Logical Model (even if it’s empty), and that a relational model can have no physical models, one physical models, or many physical models.
Does the logical model really exist, if there’s nothing in it? Try deleting it from the tree
I reckon it’s always there as a placeholder, and that’s a requirement of our design. So practically speaking it doesn’t exist, but it’s there if you use it or not.
Feb 21, 2013 @ 17:03:44
Okay – so you got your optionality reversed on the relationship between Relational and Physical (at least via Barker Notation anyway).
The logical model **bucket** exists in the tree, yes, but there is no model in the bucket, therefore it does not exist. It’s kind of a a Zen thing (like What is the sound of on hand clapping?)
So that relationship should be fully optional as you are not required to have a Relational Model either if you have a Logical, and you can definitely define a Relational Model without have a Logical to start from.