And time for a new set of tips!
But before I continue: I recently gained access to the Professional version of Visual Paradigm which provides a lot of new options and therefor also more material for new tips and tricks. However… I won’t forget my favorite Modeler edition which I have been using for so many years. Therefor I’ll make sure to mention if a tip isn’t generic but applies to a specific version. I’ll also try to keep my tips a bit varied; trying to provide something for everyone 
A quick model duplicate
Here I have a deployment diagram and I’m about to create an overview of all the diagrams which I have stored on my personal VPository cloud. The diagram component contains quite a bit of meta-data (you can see the tagged value) and this information applies to all my diagrams. The only thing which changes is the name and optionally the type (there are also 2 sequence diagrams).
Creating a new component would take quite a bit of time, also because of all the relevant meta-data. Fortunately we don’t have to: Control-E. Just select the model element you want to copy (“duplicate”), press Control-E (keep the control key pressed and press ‘e’ (not including quotes)) and you’ll get a new copy in no time.
But it gets better…
Visual Paradigm doesn’t blindly duplicate the one element you selected, if the model element contains any related elements then those will also be copied. This is what happens if I select the VPository node, and then press Control-E:
(note: I did move it a little bit out of the way to clearly show what has happened).
Of course you may not always need new copies, as I explained in my previous post a new view can sometimes also suffice. But if you do need a new copy then that is but one keypress away.
Do more with ERD diagrams
Designing a good redundant database can be much trickier than you may realize at first. It’s all too easy to come up with a design, only to discover that some parts of the data might end up getting stored multiple times. Data redundancy is key, and this is also why we have so called relational databases.
The importance of data redundancy
I’m not going to explain the database design process in full detail because that would become much too complex. But I would like to share a simple example. Let’s say we’re going to create a guestbook for modeling enthusiasts and we would like to store their name, how much years they’ve been using modeling techniques, which country they live in and finally their favorite CASE tool and their favorite UML diagram.
Should be simple enough, right? Well, maybe not so much… Because what would happen if we got several visitors from the same country? Or what if several visitors like the same diagram type? Well, then you might end up with something like this:
See what is happening here? Our database would store the text “Netherlands”, “Use Case” and “VP Professional” multiple times. Not much of a problem in the example above, but now imagine that this guestbook will be used in an international modeling Expo which expects around 5000 people. That is a lot of extra data, therefor also a lot of extra storage space which would be effectively wasted.
The solution? Simple: split up our database into multiple parts so that we can store the data separately and even better: ensure that we can re-use our data as well.
For example:
Here I created 4 so called tables, and the effect is clearly visible: we’re now only storing 1 copy of every name, therefor saving up precious resource space! The lines you see between these entities show that we have a so called 1 on 1 relationship between them. A user will have 1 associated country (you usually only live in 1), one associated tool (Visual Paradigm of course ) and finally one favorite diagram.
Design & Deploy!
Hopefully you can imagine how creating a good database design can become quite a challenge. This was a rather simple example, but now try to think about something more complex. Like a sales database, or maybe an ATM transaction database, things like that.
Well, as you’ve seen above Visual Paradigm can really help us out with this. But it gets better… In my example above I used a so called conceptual design, meaning that I only focused myself on the general design without bothering myself with details, such as field types (= the format in which data gets stored; like a number, or a string, and so on).
I can add these details by changing my ERD diagram from a conceptual design into a physical design. For example:
As you can see the diagram now also shows field types and a small key icon is also shown to indicate a so called primary key. So now that we have all this, how do we get our database design into an actual database server?
Elementary my dear reader! And the best part: even usable in the Modeler edition 
If you’re using a Modeler version then right click in the ERD diagram, find the ‘Utilities’ section and then select “Generate SQL…”. If you’re using the Standard edition (or up) you can also use the ‘Db’ icon on the ‘Tools’ toolbar and find the ‘Generate Database’ option. This will instruct Visual Paradigm to either generate the SQL code, or to directly apply your design onto the database server.
(Generate SQL option: all I have to do next is click the blue cog icon)
And the result? Well, that should be obvious enough:
Now, this showcases PostgreSQL, but Visual Paradigm supports all the major servers; from MySQL, MariaDB and MS SQL Server right down to Sybase, Informix and SQLite (and at least 12 more).
So not only does Visual Paradigm provide an option to carefully design your database(s), it also allows you to deploy your design so that it can be put to use right away. And if you think that’s a neat trick how about a reverse?
That right: once Visual Paradigm can access a database server you can also tell it to analyze the database structure and generate the ERD entities based on that. But: that’s an option which is available in the Standard edition and up.
Element grouping
Say I have a Use Case diagram but for some reason I need to create more space because additional information needs to be added.
Now, this is going to be a lot of trouble because as you can see I already used a specific design here. The two systems (WordPress and VPository) are easy because moving those will also include the contained use cases, but everything else?
Fortunately Visual Paradigm provides a very easy solution for this: grouping. This will instruct Visual Paradigm to treat several model elements as if it was one bigger element; once you click on one element you’ll automatically select the whole group.
It’s very easy to use: first select all the required elements. You can do this by dragging a selection box over them, or by clicking on the first element and then keeping control pressed while you select the others.
Then simply right click and find the ‘Grouping’ option in the menu or click on the “Group” icon which can be found on the ‘Diagram’ tab:
In the example above this would allow me to drag the VP actor and all its associated use cases easily out of the way, thus quickly freeing up room.
And there you have it…
Three more tips which you can use.
