Database Design with MySQL WorkbenchA Round Trip Software Engineering Case

Jerzy Letkowski

Prerequisites - Downloads• MySQL Server and MySQL Workbench are expected to be installed. The setup program(s) can be

downloaded from the MySQL Website.

• This instruction uses the server and workbench installed using the July 5, 2018 installer, downloaded from http://www.mysql.com/:

➢ Tab: Downloads (GA)

➢ [Scroll Down] MySQL Community Edition (GPL): Community (GPL) Downloads »

➢ MySQL Community Server (GPL)

➢ Windows (x86, 32, 64-bit), MySQL Installer MSI : Go to Download Page

➢ [Scroll Down] Windows (x86, 32-bit), MSI Installer 8.0.11 230.0M

➢ No thanks, just start my download.

• The mysql-installer-community-8.0.11.0.msi version was available, at the time of writing this instruction.

• Other major operating systems are also supported, including Mac OS X and Linux.

Download

Prerequisites - Installation

• Using the standard Window installer is pretty straight forward. Just follow the default developer's options.

• It is very important that you do not forget the root password.

• When done, follow the remaining slides to learn more about database design and implementation, using MySQL Workbench and Community Server.

You can start MySQL Workbench by using Windows search for MySQLand picking it from the list.

Click the Models icon to open the data modeling facility.

The front page of the MySQL Workbench program shows the initial (root) connection , the Models' interface.

Click the Models + icon in order to create a new relational database model.

Double-click the default schema (database) name tab (mydb) in order to create a new database name.

Type name election, and double-click the Add Diagram icon.

The Toolbar contains graphical tools that are used to paint Enhanced Entity RelationshipDiagrams (EERDs).

MySQL Workbench opens the Diagram canvas along with other useful panels, including the Birds Eye view panel, and Catalog Tree panel.

Basic Tools:TableRelationships:1:1 (One-to-One) Non-identifying 1:n (One-to-Many) Non-identifying1:1 (One-to-One) Identifying 1:n (One-to-Many) Identifying n:m (Many-to-Many) Identifying1:n (One-to-Many) Using Existing Columns

Problem StatementA Database for an Online Voting System

Our mission is to design a database for an on-line election system that will be utilized to conduct election of new leaders of a non-profit organization. The organization has members some of which hold leadership positions (president, vice president, treasurer, newsletter editor, annual meeting coordinator, secretary, etc.). Some of the members have been nominated to run for the positions. Assume that they have already accepted their nominations, thus becoming official candidates for the available positions. The organization’s statute states that each candidate may only run for one position and each member may cast no more than one vote for each of the positions. The database should facilitate the voting process and record all votes assigned to the candidates but it should not tell which member has voted for which candidate.

Entities

From the problem definition one could identify the following base entities: • Member: a list (set) of members of the organization, some of whom are candidates;• Office: a list of positions ('president', 'treasurer', 'editor', etc. ); Other entities result from associations between the base entities.

Our mission is to design a database for an on-line election system that will be utilized to conduct election of new leaders of a non-profit organization. The organization has members some of which hold leadership positions (president, vice president, treasurer, newsletter editor, annual meeting coordinator, secretary, etc.). Some of the members have been nominated to run for the positions. Assume that they have already accepted their nominations, thus becoming official candidates for the available positions. The organization’s statute states that each candidate may only run for one position (office) and each member may cast no more than one vote for each of the positions. The database should facilitate the voting process and record all votes assigned to the candidates but it should not tell which member has voted for which candidate.

To add entity (table) Member to the data model (EER diagram) click the New Table icon.

Entity Member

Next click anywhere on the Diagram canvas.

In order to change the name of the table and add its attributes, double-click table table1.

MW (MySQL Workbench) inserts the new table named as table1. This table is supposed to become the Member table.

Type name Member.

Add column name midas (Datatype) INT.

Set column mid as the Primary Key (PK).

Add other columns:firstName as VARCHAR(45),lastName as VARCHAR(90),pass as CHAR(12),email as VARCHAR(90).

Notice that the primary key is automatically set as Not NULL (NN). Data types INT, VARCHAR and CHAR stand for an integer, a variable-length string (text) and a fixed-length string, respectively.

When done, close the Member - Table definition panel.

Some individual have hard time of visualizing abstract entities. The attached Excel macro-workbook, election.xlsm, contains different depictions of the entities.

Each worksheet shows three representations for each of the election-database entities: ERD (UML), SQL and Excel Table.

The election.xlsm workbook also contains a macro-function,

sqlInsert(table_name_abs_ref,data_type_abs_ref,record_ref),

that transforms rows of the tables into their SQL-Insert statements. In order to facilitate this function, a row with "high-level" data types is added (right above the column names), where n stands for numeric and c—nonnumeric.

Note that the last part of this instruction shows how to transform the ERD view into the SQLstatements. Typically, when designing a new database, the SQL representations are not available until the ERD model is completed and transformed to it. At this point, SQL (Structured Query Language) may be somewhat mysterious (it will be explored in detail later). Suffice to say, it is the official language for managing relational database systems. It is shown here for completeness.

The Member worksheet of the election.xlsm workbook shows three views of the Member entity: UML, SQL Schema, SQL Data, and Excel Table.

The sqlInsert() function transforms the rows of the Excel Table into SQL-Insert statements.

CREATE TABLE Member

(

mid int primary key,

firstName varchar(45) NOT NULL,

lastName varchar(90) NOT NULL,

pass char(12) NOT NULL,

email varchar(90)

);

To add entity (table) Office to the data model (EER diagram) click the New Table icon.

Entity Office

Change the name of this table to Office.

Add column oid as INTand PK.

Add column title as VARCHAR(45).

When done, close the Office – Tabledefinition panel.

CREATE TABLE Office

(

oid int primary key,

title varchar(50) NOT NULL

);

The Office worksheet of the election.xlsm workbook shows three views of each of the Office entity: UML, SQL Schema, SQL Data, and Excel Table.

The sqlInsert() function transforms the rows of the Excel Table into SQL-Insertstatements.

This instruction shows how to develop an EER diagram (ERD) in which relationships are modeled using the UML notation. Make sure that your notation is the same.

Select the following menu options: Model

Relationship Notation,UML.

To add a relationship between entities Member and Office, click the m:n Identifying Relationship button.

Notice that m:n stands for Many-to-Many. Since a member (instance of entity Member) participates in election of many offices (positions) and a given office (instance of entity Office) is being elected by many members, this is a Many-to-Many relationship. Note: Despite selecting the UML notation, the relationship tools are shown, using the Crow-Foot notation.

In order to customize the Member-has-Office entity, double-click this entity.

MW inserts a new [default] entity, Member-has-Office and sets the relationships of this entity with Member and Office to Many-to-One. This is a typical resolution of the Many-to-Manyrelationships as required by the relational database model.

Notice that the new entity has received two keys from the associated entities. Their sources are the primary keys (mid and oid) of the base entities. Jointly, they constitute a [composite] primary key of the new entity's .Individually, they are foreign keys.

Change the name of this entity to Ballot.

Change the names of the first two columns to:

mid,oid.

Add a new column (attribute):ballotPickupTime as DATETIME.

When done, close the Ballot – Tabledefinition panel.

Double-click the Member - Ballot link.

Since theoretically there may be members who will not participate in the election of their representatives (officers), the participation of the Ballot entity in the relationship with entity Memberis optional. The cardinality constraint at the Ballot side should be changed from many-mandatory (1..*) to many-optional (0..*).

Select the Foreign Key tab and uncheck option Mandatory in the Ballot panel.

When done, close the Relationship panel.

Double-click the Ballot – Office link.

Since theoretically there may be Office instances (positions) that will not receive any votes (at any given time), the participation of the Ballot entity in the relationship with entity Office should be optional. The cardinality constraint at the Ballot side should be changed from many-mandatory (1..*) to many-optional (0..*).

Select the Foreign Key tab and uncheck option Mandatory in the Ballot panel.

When done, close the Relationship panel.

CREATE TABLE Ballot

(

mid int primary key,

oid int NOT NULL,

ballotPickupTime DateTime,

FOREIGN KEY (mid) REFERENCES Member(mid),

FOREIGN KEY (oid) REFERENCES Office(oid)

);

The Ballot worksheet of the election.xlsm workbook shows three views of each of the Ballot entity: UML, SQL and Excel Table.

The sqlInsert() function transforms the rows of the table into SQL-Insertstatements.

Looking at the relationships between the entities defined, using the primary and foreign keys, one can see that, for example, 'Ann' (pk: mid=1 in Member) picked her ballot for the office of 'President' (pk: oid=1 in Office) at ballotPickupTime='2009-10-03 18:32'. In table Ballot, the foreign keys, mid and oid, are set for this relationship to the values of the primary keys of 'Ann' and 'President', respectively. Jointly, in table Ballot, the keys mid and oid constitute the primary key.

There is no requirement for a foreign key to have the same name as its related primary key. Nonetheless, having the same names may simplify documentation and query development as long as it is clear which are the primary keys and which are the foreign keys. Some of the SQL queries, involving more than one related tables can be simplified when the keys have the same names.

Notice that MW has generated the foreign key with names made of the entity names and their primary-key names (Member_mid and Office_oid) and we changed them to mid and oid, respectively.

In this instruction, all primary keys and their corresponding foreign keys will have the same name. Thus, the primary key, mid, of the Member table will propagate to other entities as a foreign key with the same name (mid). The primary key, oid, of the Office table, will also have the same name for all related foreign keys. It will make SQL queries look more slick and compact.

The model developed so far does not include important individuals: candidates who are running for offices. Each candidate must be a member (an instance of entity Member) but only some of the members are candidates (instances of entity Candidate). The relationship between Candidate and Member is hierarchical. Candidates inherit all the attributes from related members. Such a relationship is modeled in UML as specialization (a candidate is a specialization of a member) also known as a Super-type – Sub-type association*. MySQL Workbench does not support such a notation. However, it supports this type of the relationship as an One-to-One relationship with optional participation of the subtype entity (here Candidate).

Member

Candidate

Member

Candidate

1

0..1

* In an object-oriented language , Member would be a super-class and Candidate—a sub-class. Java would say that class Candidate extends class Member.

Since there will be more entities and relationships in the model, why don't we rearrangethe entities approximately as shown below. It can be done by simply dragging the entities around.

Now, click the New Table icon.

Click the diagram canvas to add a table.

Double-click the new table and change its name to Candidate.

When done, close the Candidate – Table panel.

Connect entity Candidate with entity Member using the 1:1 Identifying Relationship tool.

More specifically, first click the 1:1 tool, next click table Candidate and finally click table Member.

We use the identifying relationship tool 1:1 since entity Candidate will be [uniquely] identified by the Member's ID (mid).Each candidate is one and only one member.Notice that the identifying relationship links are shown as solid lines.

To change the name of the inherited table, double-click entity Candidate and change column-name Member_mid to mid.

When done, close the Candidate – Table panel.

Notice that the inherited

attribute, mid, serves in

entity Candidate as

both the primary keyand the foreign key.

To change the cardinality constraint at the Candidate entity, first double-click the Member - Candidate link.

Select the Foreign Key tab and uncheck option Mandatory in the Candidate panel.

When done, close the Relationship panel.

A One-to-Many relationship is directional. When connecting the related entities, MWrequires that the entity on the Many side be selected (clicked on) prior to selection of the entity at the One side. The latter maps its primary key to the foreign key of the former.

The relationship we are about to create is:

Office (1) — is-being-run-for-by — (1..*) Candidate

(In order for an instance of office, e.g. 'President', to be part of the election, there

must be at least one candidate running for it.)

This relationship can also be defined as:

Candidate (1..*) — runs-for — (1) Office

Since an office may have many candidates, it is responsibility of the candidates to "know" which offices they are running for. Thus each instance of entity Candidate must include "information" about the office s/he is running for. This information is nothing else but the foreign key in the Candidate table pointing to the primary key in the Office table.

Select (click) the Non-identifying One-To-Many Relationship tool.

Now it is a good time to further specialize entity Candidate. What distinguishes a candidate from a member is that the former is [deterministically] running for an office. Since a candidate may run for only one office and an office may have many candidates, the appropriate relationship between Office and Candidate is a One-To-Many (1:n) Non-identifying Relationship.

We use the non-identifying relationship tool since entity Candidate already has a primary key.

Click the Candidate table and then click the Office table.

MW connects entity Office with entity Candidate with a One-To-Many (1 : 1..*) Non-identifying Relationship. Notice that this non-identifying relationship link is shown using a dashed line.

Double-click the Candidate table and then change column name Office_oid to oid.

When done, close the Candidate – Table panel.

CREATE TABLE Candidate

(

mid int primary key,

oid int NOT NULL,

FOREIGN KEY (mid) REFERENCES Member(mid),

FOREIGN KEY (oid) REFERENCES Office(oid)

);

The Candidate worksheet of the election.xlsm workbook shows three views of each of the Candidate entity: UML, SQL and Excel Table.

The sqlInsert() function transforms the rows of the table into SQL-Insertstatements.

Looking at the relationships between the entities, defined by means of primary and foreign keys, one can see that, for example, 'Ann' (pk: mid=1 in Member) is a candidate (pk: mid=1, having fk: mid=1 and oid=4 in Candidate) who is running for office of 'Editor' (pk: oid=4) in Office. In table Candidate, the foreign keys, mid and oid, are set for this relationship to the values of the primary keys of 'Ann' and 'Editor', respectively. In table Candidate, the key mid plays a dual role. It is both the primary and foreign key (resulting from an identifying relationship).

Since there will be one more entity and relationship in the model, why don't we rearrange the entities approximately as shown below. It can be done by simply dragging the entities around.

When done, click the New Table icon.

Click in the middle of the diagram to place a new table there.

MW adds a new entity (table1) to the diagram.

Double-click the new table.

Change the name of this table to Vote and add columnvid of type INT as a primary key.

When done, close the Vote – Table panel.

Select (click) the 1:n Non-identifying Relationship tool.

Entity Vote serves here are a set of votes cast for the candidates. Since a candidate may get many votes and each vote is cast exactly for one candidate, Candidate – Vote is a One-to-Manyrelationship.

First click the Vote table and then click the Candidate table.

MW connects entity Candidate with entity Vote with a One-To-Many (1 : 1..*) Non-identifying Relationship. This relationship needs to be “relaxed” as there may be candidates who will not receive any votes.

Double-click the Candidate - Vote relationship link.

Select the Foreign Key tab and uncheck option Mandatory in the Candidate panel.

When done, close the Relationship panel.

Change the name of column Candidate_mid to mid.

When done, close the Vote – Table panel.

CREATE TABLE Vote

(

id int primary key auto_increment,

mid int NOT NULL,

FOREIGN KEY (mid) REFERENCES

Candidate(mid)

);

The Vote worksheet of the election.xlsm workbook shows three views of each of the Vote entity: UML, SQL and Excel Table.

The sqlInsert()function transforms the rows of the table into SQL-Insertstatements.

Examining the relationships between the entities, defined by means of primary and foreign keys, one can see that, for example, candidate 13 (fk: mid=13 in Candidate) has received 5 votes (pk: vid=2, 3, 7, 11, 13, with fk: mid=13 in Vote).

The logical phase of the database design is done! It has enough details (tables, attributes, primary keys, foreign keys and cardinality constraints) so that it can be transformed into an executable SQLmodel. MW can do this transformation via its Forward Engineer SQL export facility (menu options):

File > Export > Forward Engineer SQL Create Script ...or

Database > Forward Engineer ...

The following instruction shows how to do it using the latter command.

Make sure that your EER diagram is saved!

Select menu options Database followed by Forward Engineer.

Use your root connection and click button Next.

Select (check) options Drop Objects Before Each CREATE Object, Generate DROP SCHEMA, and Generate Separate CREATE INDEX Statements and then click button Next.

Select (check) just one option, Export MySQL Table Objects, and then click button Next.

Save the script to a file, click button Copy to Clipboard, and then click button Next.

MW generates an SQL script, including all statements necessary to create the database, election, tables (Member, Office, Ballot, Candidate and Vote) as well as indexes of the foreign key for tables (Ballot, Candidate and Vote).

Click button Close.

MW connects to the server (DBMS) and executes the SQL script. The logical design has just been transformed [automatically] into a physical database.

Select (click ) menu options Database and Connect to Database ... .

Why don't we connect to the election database and add a few records to the tables. The election.xlsm workbook contains sample Insert statements.

Use the root connection. Type name election for Default Schema and then click button OK.

Expand the election tree in order to reveal the tables.

MW opens a Query panel and reveals all existing databases in the SCHEMAS panel. A full expansion of the election tree will show more details, including column names.

Select and copy all the Insert Statements.

Switch to the election.xlsm workbook andselect the Member worksheet.

Switch back to the Query panel in MW and press Ctrl+V, in order to paste the Insertstatements.

With all the Insert statements in the Query panel, click the Execute button.

The Output panel shows feedback for each of the executes statements.

In order to clear the Query panel, select all the Insert statements (press Ctrl+A) and pressthe Delete key.

In a similar way, bring the other Insert statements (for tables Office, Ballot, Candidate and Vote) from the Excel workbook, election.xlsm , to the MW's Query panel. Execute the statements and explore the database by running a few queries.

Type statement SELECT * FROM Office; into the Query panel and click the Execute button.

After all the sample records have been added, run a few queries. The first example shows all positions stored in the Office table.

Query result!

Query status!

Type statement SELECT * FROM Member WHERE mid IN (SELECT mid FROM Candidate);

into the Query panel and click the Execute button.

The second example shows all the candidates.

The same result can by done by an explicit JOIN statement:SELECT * FROM Member JOIN

Candidate USING(mid);

Type statement SELECT * FROM Member JOIN Candidate USING(mid) JOIN Office USING(oid);

into the Query panel and click the Execute button.

The third example shows all the candidates and offices they are running for.

Type statement SELECT mid, lastName FROM Member WHERE mid NOT IN (SELECT mid FROM Ballot);

into the Query panel and click the Execute button.

The fourth example shows all the members who have not yet picked any of their ballots.

Using an existential query:SELECT mid, lastName

FROM Member

WHERE NOT EXISTS

(SELECT * FROM Ballot WHERE Ballot.mid=Member.mid);

Type statement SELECT mid, Count(Ballot.mid) FROM Ballot GROUP BY mid;

into the Query panel and click the Execute button.

This final example shows the number of positions the members have already voted for.

Notice that one of the members have picked up only one ballot.

This concludes the Forward Engineering case, including the logical design and schema generation, extended by populating the databases with sample records and running queries. The remaining slides show how to Reverse Engineer an existing [physical] database. It is a good time to save and close MW (MySQL Workbench). Then start a new instance of MW (a fresh start).

Start MySQL Workbench and select the Data Model option (see slides 4 and 5 for details).

Click Button > and select the Create EER Model from Database.

Use your root connection and click button Next.

Click button Next.

MW is connecting to the server and retrieving the existing schemas from the DBMS.

Select database election and click button Next.

Click button Next.

Make sure options Import MySQL Table Objects and Place imported objects on a diagram are selected and click button Execute.

Click button Next.

Click button Finish.

Drag the tables around in order to better organize the diagram.

The table objects are not arranged in a friendly way.

Double-click the Member - Candidate relationship link.

Notice that the diagram is almost identical to the original one (developed manually). The critical difference is that the relationship between Member and Candidate is shown as One-to-Many (1:1..*).

Click the Foreign Key tab. Uncheck the Mandatory option in the Candidate panel.

Turn on the One-to-One (1:1) cardinality option.

When done, close the Relationship panel.

Using similar operations, modify the Member – Ballot, Ballot – Office and Candidate – Vote relationships. Make sure that the Mandatory participation of entities Ballot and Vote are turned off so that they will all show up as 0..* (Optional-Many).

A perfectionist would also show the table names in the title case. Finally, save the model and close MW.

This is it!