The thing that got me writing this article was a question posted on Stack Overflow about data design, asking whether it’s better to use one big table or to arrange the data using multiple related tables.  Having spent many years working with relational databases this seems obvious, it’s easy to forget this is not common knowledge and assume everyone knows this stuff.

The examples below are from a database that contains information about portraits belonging to the University of Oxford.  These portraits are referred to as Works in the database.

The database also holds details of the  people connected to the portraits. This includes the subject of the portrait (the sitter),  the artists who produced the portrait, and others such as donors who have bequeathed portraits to the university.

A portrait may be connected to many people and a person may be connected to many portraits, in other words a many-to-many relationship exists between portraits and people.

There are various ways in which this can be modelled:

• Store the portraits and people in a single table. When several people are linked to a portrait can either have multiple sets of columns to hold the extra people or have multiple rows where the portrait data is repeated
• Store the portraits and people in two separate tables with columns in the portrait tables that hold the links to the various people
• Store the portraits and people in separate tables with a third table to hold the relationships

The problem with the first two solutions above is that data is either repeated or is left empty in case it is required as we can’t know up front how many relationships there will be for each portrait and person.  They are also hard to change when new requirements are identified, e.g. a new type of person needs to be added.

The third solution doesn’t require repeating (redundant) data or booking spaces for relationships that may or may not be required, using data modelling terms we can say it has been normalised.

The extra table by convention is named from concatenating the names of the two tables in the many-to-many relationship, hence the new table in our example is called Work_People as it links the Work and People tables.

The new table is constructed by taking the Primary Key of each of the parent tables. These become the primary key of the new table. In our example both tables have numeric primary keys that are incremented for each new row. Using these abstract keys allows the data in the tables to be changed without having to update the relationships, e.g. the names in the People table can be changed without having to update the Work_People or Work tables.

Note the relationships in the diagram between the three tables.  The connectors that link the tables have a single terminator at the One end of the relationship and have a crows foot at the Many end of the relationship.

There is a One at the One end of the relationship

There is a Zero at the Many end of the relationship.

This is the cardinality of the relationship which means the connector between the Work and Work_People tables can be read as Exactly One row in the Work table can be related to Zero or More Work_People rows.

In other words, new rows can be added to the Work and People tables without having to add relationships to the Work_People table. This allows new works and new people to be added independently of each other,  then the relationships are added as and when required. Note that this isn’t always the case, cardinality will vary and in some cases may specify that the relationships must be added at the same time as the rows in the main tables.

While writing an article on implementing Many to Many Relationships in databases the need for a diagramming tool became clear.  At  work Visual Paradigm is the tool for all UML and data modelling requirements, so it was good to read there is a free community edition that can be downloaded for personal use. The Community Edition page has a link on the left hand-side to download Visual Paradigm.

Clicking  on the round image highlighted in yellow will prompt for registration or a user name and password.  Once you have registered the next page has two checkboxes,  select the second check box to request a license key as an attachment, this will be sent as an email to the address provided during registration.

Then click on the Download button to start downloading the large (140 Mb) executable file.  Once it has been downloaded running the executable will start the installation procedure, you will be prompted for location and so on. When the installation procedure prompts for the product to be installed, make sure you select Visual Paradigm for UML.

The next dialog to be displayed prompts for the edition to be used,  select the Community Edition as that is free for personal use.

The final dialog prompts for the license to be used. Select the Single License Key option and in the file path box enter the path and the name of the license key file that was attached to the registration email.

That pretty much completes the installation. When you first run Visual Paradigm you will be prompted for a workspace which is where all of the diagrams you create will be stored.  Make sure this is set to a path of a location that does get included in backups, particularly if you plan to create diagrams that would be difficult to recreate if they were lost due to a disk crash.

The next part of this article will describe how to get started with  Visual Paradigm and how to create the first Entity Relationship diagram.