ICT581 Information Systems Principles and Practice

Tutorial 9 – Database Design

LEARNING OUTCOMES FOR THIS TUTORIAL

After completing this workshop you should be able to:
• Create an ERD from a given case using the crow’s foot notation
• Use Visio to create an ERD and legend
• Recognise several typical ER modelling structures

Online: ERDs in Visio 2016 https://www.youtube.com/watch?v=upR0vmmzvm4

Visio 2019 in general https://support.office.com/en-us/article/Tutorial-for-Visio-2016-
c8fd9b8b-6e8c-4252-937d-a0eea0cddd94

1. DRAWING THE VIEW RIDGE GALLERY ERD USING VISIO 2016

Note that the following instructions refer to Visio 2016, the version in the labs. Unfortunately this
version has lost most of the useful functionality from updated version of Visio, which allowed you to
create properties of the data model that flowed through to the logical/physical designs. Visio 2016 is
largely a drawing tool but does let you create primary keys and foreign keys and the different
relationship cardinalities.

→ Start Visio

→ Select the Software and Database category:

1
→ And then Crow’s Foot Database Notation:

→ Select Metric from the next dialog box and click OK to create a new ERD.

Visio should open at a blank page with the ERD template shapes to the left hand side.

→ Create an entity on your diagram by left clicking the Entity symbol and dragging it on to the page.

→ If the entity is too small to see, increase the zoom on the page until it can be seen.

2
→ Select the entity you have just created by double-clicking in it and change the Entity Name to
CUSTOMER.

→ Add CustomerID as the PK attribute:

→ Add LastName and FirstName attributes.

→ Select the LastName attribute by clicking in it:

→ Right-click to see the attribute menu. Notice that you can set the primary key and foreign key
here.

→ Choose ‘Set Required’ to indicate LastName cannot be left blank. Notice that the attribute name is
now bolded.

→ Set FirstName to Required as well.

3
→ Now add the remaining CUSTOMER attributes: Street, City, State, ZipPostalCode, Country,
AreaCode, PhoneNumber, Email. You will need to add new attributes to the entity by selecting
the option from the attribute right-click menu, or by dragging the attribute symbol to your entity
from the shapes.

→ Also spend some time investigating the colour schemes available for the diagram. You can also
change the font, size and colour to something that is more readable.

→ Now create a WORK entity and add the details as below:

WorkID Primary Key

Title NOT NULL
Copy NOT NULL
Medium
Description

4
→ And add the TRANS entity, using the following attributes:

TransactionID Primary Key

DateAcquired NOT NULL
AcquisitionPrice NOT NULL
AskingPrice
DateSold
SalesPrice

Next, you will create the relationships between the three entities.

→ Create the relationships between CUSTOMER and TRANS, and between WORK and TRANS by left
clicking the Relationship icon in the ‘Shapes’ area and dragging it onto your diagram. You will need
to move the endpoints of the line to the relevant entities.

→ Set the cardinality at each end of each relationship line from the right-click menu of the
relationship, as shown below.

→ Choose Format Shape from the right-click menu of the relationship line to change the size of the
crow’s feet to Extra Large or Jumbo, as the default is unreadably small.

5
→ Next, we will add the foreign key attributes to the TRANS entity. In Visio 2010, the act of defining
a relationship would automatically add the foreign key, but in Visio 2016 foreign keys need to be
added manually.

→ Add CustomerID and WorkID to the TRANS entity. Define each of them as Foreign Key, and set
them to Required.

→ Finally, we will make both the relationships Non-Identifying. This means that the TRANS entity is
not dependent on WORK or CUSTOMER for its primary key.

6
→ Select the relationship line between CUSTOMER and TRANS, and from the right-click menu untick
the option ‘Set Identifying’. Do the same for the relationship between WORK and TRANS.

→ Save your work!

2. A WORD ON LEGENDS
You should get into the habit of including a legend with every diagram you draw. The legend should be a
key to all of the different symbols in the diagram, enabling the reader to interpret it. In an ERD, the
legend would contain the entity symbol, including entity name, attributes, PK, FK and required
attributes; and the relationship symbol, showing all the crow’s feet types and their meanings. If your
ERD includes additional symbols such as subtypes and supertypes, include them in the legend too.

• Create a legend for the Visio 2016 notation you have been using in this lab. Make it from
scratch, by including all relevant symbols and their labels in a compact format, rather than trying
to use any ‘legend’ feature in the software. Creating a good legend now will save time in your
assignments later!
• This is an example of legend.
LEGEND

ENTITY_NAME Non-identifying relationship

Identi fying relationsh ip

PK PrimaryKeyAttribute

AttributeName Zero or more

RequiredAttribute 1 or more

1 and only 1
FK ForeignKeyAttribute
Zero or 1

7
3. Now try this: THE EMPLOYEE-WORKS ON-PROJECT CASE
This simple (and quite contrived) case has several elements that you will commonly encounter:
• Resolving a M:N relationship into two 1:M relationships
• 1:1 relationship
• 1:M relationship
• Multi-valued attributes
• Invoice/Line-item/Product (or variations thereof)

As you work through this example and read the hints, note how the structures come together. Think
carefully about whether the relationships are mandatory or optional. Think also about other situations
in which each of these examples might be relevant.

Create the ERD using Visio on a new page of your Visio file. If you prefer, sketch it on paper first.

1. A project (which has a Project ID and a name) has many employees working in it. Each employee
has an EmployeeID and a name. An employee can work on many Projects. When an employee
works on a project, there is a billing rate assigned (e.g. when Emp 1 works on Proj 1, his billing
rate is $15, when he works on Proj2, the billing rate is $17.50. When Emp 2 works on Proj 2, her
billing rate is $23.

• This is a M:N relationship. You need to resolve this into two 1:M relationships. In this case, I
would create entities called PROJECT (PK ProjectID) and EMPLOYEE (PK EmpID). To resolve the
M:N, you will need to create a third entity (an intersection entity) called something like
WORKS_ON or PROJECT_EMPLOYEE, which will also include the BillingRate which is an attribute of
the relationship.

2. Each project must have one project manager who is one of the employees. An employee cannot
manage more than one project.

• This is a separate relationship between EMPLOYEE and PROJECT. It will have mandatory
participation in one direction – i.e., each Project MUST HAVE a ManagingEmployee, and optional
in the other – i.e., each Employee will Manage zero or one projects.

3. Each employee can have one emergency contact (telephone number)

• This is an example of dealing with a 1:1 relationship. The important decision in 1:1 relationships
is which of the entities should have the Foreign Key? Generally, it will be the one that will result
in the least number of nulls. An option here would also be to include the Emergency Contact’s
details with the employee, though this would result in nulls where the employee did not have an
emergency contact.

4. An employee can have more than one telephone number.

8
 • Multi-valued attributes. As multi-valued attributes aren’t allowed in a relation, we can’t show
this as a single attribute ‘telephone numbers’, so must deal with it in a different way.

We could possibly represent it with by having a number of attributes in the employee entity e.g.,
Mobile, Home, Office etc. However, the more flexible design option here (in case there is a new
type of phone??) would be to create a separate entity for telephone. The type of number (e.g.,
home, mobile etc) could also be an attribute.

5. Each project consumes parts. Whenever a project orders parts, they are recorded on an Invoice
(which has an invoice number and a date). An invoice can list many individual parts and each part
on an invoice will have a quantity ordered. Each part has a Part ID, name and price. Each part is
supplied by a supplier (Supplier ID, Name)

• Classic invoice/line-item/item/supplier relationship. Most commercial transactions will have

this type of structure. Make sure that you understand how it works. Next time you go shopping,
examine the data in the receipt and match it to this common structure.