Week 1 & 2- Lab 1- Creating your First

Conceptual Model
Table of Contents
Understanding Conceptual Modeling: Instructions 1
Lab Goal & Description 1
What You Will Need to Begin 1
Part 1 – Practicing Modeling 2
A. Developing a book store’s database (Problem 3 in our Exercise Sheet): Getting royalties in. 2
B. Developing a book store’s database: Recording series of books in our model. 6
Part 2 – Create your Models 8
C. Developing a model for a Piano Manufacturer’s database (Problem 5 in our Exercise Sheet): 8
D. Expanding our model for the Piano Manufacturer’s database (Problem 6 in our Exercise Sheet): 9
E. Finalizing our model for the Piano Manufacturer’s database (Problem 7 in our Exercise Sheet): 10

Understanding Conceptual Modeling: Instructions

Welcome to your first activity in IS680! We will be practicing the development of multiple
conceptual models with increasing levels of complexity. The first part of the lab consists of a series of
instructions to guide you in developing your first conceptual model, while the 2 nd part you will apply
your recently gained abilities and use your freedom to develop a model for a separate database process.

What You Will Need to Begin

- Visit draw.io (https://www.draw.io) to gain access to a modeling tool either through its web
version or by downloading a copy into your own computer.
- Please complete the modeling exercises in draw.io and copy your models (with your name
visible) into this document.
Part 1 – Practicing Modeling

In this section we will go through different modeling scenarios to strengthen our skill in:

1) identifying entities, attributes, and relationship types in a series of business rules and
requirements.
2) Model the identified entities, attributes, and relationships within a modeling tool (like draw.io).

A. Developing a book store’s database (Problem 3 in our Exercise Sheet): Getting

royalties in.

The first 2 exercises discussed in class gave us the opportunity to examine the relationship between
books and publishers (Problem #1) as well as between Books and their authors (Problem #2). However,
these problems only tell us a limited story.

If we would like to record new things such as profitability, we need to start considering expansions
to the model. For example, we can look take a look at the following problem which tell us of the need to
record the royalties earned for each book by different authors. To be able to record this, we need to
modify the model using the following paragraph as a guide:

Description of Requirements:

In the context specified by problems 1 and 2, we need better information regarding the
relationship between a book and its authors. Specifically, it is important to record the percentage of
the royalties that belong to a specific author, whether a specific author is a lead author of the book,
and each author’s position in the sequence of the book’s authors.

This paragraph gives us some clues as to what we need to do. Specifically, it tells us of the entities
and their attributes needed based on our current situation, as well as how they are related to each
other. When presented with such a scenario, we simply need to look at each sentence individually an
examined them for clues on what a) entities, b) attributes (for each entity), and c) relationships are
needed.

Let us start by taking a look at each sentence individually and examine them for clues that can
inform our models:

First Sentence:

In the context specified by problems 1 and 2, we need better information regarding the relationship
between a book and its authors.
 The first thing we should consider is whether this sentence (think business rule) tells us anything
about a needed but currently missing entity. In this particular case the sentence just tells us we need
information about both “books” and “authors”. From problems 1 and 2 we already knew about these
two entities and therefore we can continue to look for other factors. Taking a second look at the
sentence doesn’t seem to suggest the presence of any attribute, and while it does mention a
relationship between books and the authors, it doesn’t make the nature of the relationship clear.
Therefore, we can move on to the 2nd sentence.

Second Sentence:

Specifically, it is important to record the percentage of the royalties that belong to a specific author,
whether or not a specific author is a lead author of the book, and each author’s position in the
sequence of the book’s authors.

Following the same process as in the first sentence, we can clearly see that it is suggesting the
collection of information on a) percentage of royalties, b) authors, c) whether the author is the lead
author for a given book, and d) the author’s position in the sequence of authors of the book (i.e. first
author, second author, third author and so on).

We have already stablished that the authors are to be recorded as its own entity (problem 2)
which leaves us with 3 other pieces of information. Would it be fair to say that they are characteristics of
the authors? Well, yes and no. The percentage of royalties an author received are different for each
book making it a characteristic of both the book and the author, and the same can be said of whether
the author is the lead author, or what his/her position in the books’ authors sequence is. If they are
properties of both the books and the author, we can be confident that these 3 factors are characteristics
or properties of the relationship between both entities. These are called associative attributes in terms
of Entity-relationship diagrams (ERD). We draw them this way:
 Associative attributes are drawn as a separate box with a dashed line connecting them to the
relationship line between the corresponding entities (books and authors). Notice that since these are
attributes of the relationship rather than an entity in themselves, we neither have an entity name to
describe them nor an identifier for it (at least in conceptual models).

One alternative exists to using an associative attribute. This is to create an associative entity
instead that mediates the relationship between the main two entities of interests (Book and Author).
However, doing so means that we are consciously deciding to create a separate table later on to
incorporate these attributes. Arguably, we would do this because these attributes are important for our
context and we plan to use them significantly in the future making them important enough to merit
having their own entity. An associative entity would look like this:

As we stated before, in an associative entity we store the royalty information is its own separate
entity mediating the relationship between the book, and the authors. It would be accurate to say that
the associative entity is simply recording the records (entity instances) of one table that match with
those of a second table. In other words, they record which book matches with which author as well as
and reflects the corresponding values of its properties for the corresponding match (that is, it records
the percentage of royalties, position in sequence of authors, and whether an author was the lead or not
for every author for every book with each line uniquely representing the match of 1 book and 1 author).

Ex.: If Jhon Doe has written 3 books, the associative entity would have a line for each match of
John Doe and each of his books (line 1: John Doe and book 1, line 2: John Doe and book 2, line 3: John
Doe and book 3) and the corresponding royalties and position that John Doe receives for each of those
books.

IMPORTANT:

One key aspect you may notice is that the relationships changed. That is because originally, we
had that:

1) one book was written by at least one author but potentially more, and 2) one author could
have written many books but had not necessarily written any just yet.

Since now we are describing the relationship with a separate entity for the royalties given, we
need to rewrite the relationships in terms of the royalties generated by the book, and received by the
authors. Let’s take a look at one at a time:
 A. One book is written by at least one but potentially many authors. Rewriting this in
terms of the royalties we could see that every one book must generate royalties for at
least one but potentially many authors. At the same time, royalties being given must be
associated with exactly one book (since royalties come from a single source).
B. One author may have written one but potentially many books. Rewriting this in terms
of royalties we could see that every author may receive royalties from one or potentially
many books. At the same time, royalties being send must be given to exactly one author
(as they are required for the match of one book and one author).

This is the same thought process that we must go through whenever we are presented with a
set of business rules in general and with characteristics of a relationships between 2 entities in
particular.

Is one option (associative attribute or associative entity) better than the other?

Not necessarily, conceptual models are aimed to create representations of the world the
database needs to record. As such, we want to create accurate portrayals that communicate as much
detail as possible in a simple manner. Nevertheless (and as you will see in coming weeks), both associate
attributes and associative entities are likely to result in equivalent implementations of the database. We
can discuss this in a later session.

B. Developing a book store’s database (Problem 4 in our Exercise Sheet): Recording

series of books in our model.

Now let’s proceed to take a look at a slightly different, yet interesting case. What happens if we have
a relationship between 2 entity instances of the same entity? Let’s take a look at problem #4 for this.

D. A book (see (a) above) can be part of a series, which is also identified as a book and has its own
I S B N number. One book can belong to several sets and a set consists of at least one but potentially
many books.

The first sentence tells us that we are interested in capturing information about “Series” (that is,
books that contain other books within themselves), and that each series is “identified as a book and has
its own ISBN number”. This suggest that, ISBN are identifiers of a potential entity “Series”. Should we
include Series as a separate entity? Well, let’s see if we can get more information from the rest of the
business rules.

The 2nd set tells us that each book “can belong to several sets and a set consists of at least one but
potentially many books”. While the word set is being used, it is reasonable to assume that it is still
referring to the series we discussed in sentence #1. This (as well as the presence of the ISBN as an
identifier) suggests that a series is just a type of book, and they are actually part of the same entity
rather than separate ones (after all a book can belong to several series, and it can also consist of a
series). This tells us that what we are dealing with is actually relationship between 2 instances of the
same entity in which one instance (one book) can be part of a different instance (a different book), or
contain one or more different instances itself (contain one or more different books wihtin itself).

Hence, this is a case of a Unary relationship (I.e. an entity relating to itself). We can represent them
like this:

PS: This is the correct solution to this problem #4.

Unary relationships can certainly look confusing at first glance, but it is no different than 2 entities
being related to one another. In other words, we could envision Unary relationships as taking being 2
separate entities of the same type like this:
 While drawing the model with 2 instances of the same entity is useful to better understand the
concept, please refrain from using this format as it is not the correct way of modeling these
relationships. If needed, draw it like this to better understand it, and then recreate it in the proper
format as shown above under the Unary relationship example.

Part 2 – Create your Models

In this section we will go through different modeling scenarios to strengthen our skill in:

3) identifying entities, attributes, and relationship types in a series of business rules and
requirements.
4) Model the identified entities, attributes, and relationships within a modeling tool (like draw.io).

C. Developing a model for a Piano Manufacturer’s database (Problem 5 in our

Exercise Sheet):

Ebony and Ivory, a piano manufacturer, wants to keep track of all the pianos it makes individually.
Each piano has an identifying serial number and a manufacturing completion date. Each Instrument
represents exactly one piano model, all of which have an identification number and a name. In
addition, the company wants to maintain information about the designer of the model. Over time, the
model, and the model design is specified before any single piano exists.

Following the guidelines from the previous examples, review each business rule (each sentence) and
identify any pertinent information (entities of interest, potential attributes, and potential and types of
relationships).

Q1. What entities and attributes do each business rule (sentence) suggest we should include in the
model?

Q2. What relationships can you identify in the statements above?

Q3. Please draw a model of the needed database including the inferences made above (entities,
attributes, and relationships).
 D. Expanding our model for the Piano Manufacturer’s database (Problem 6 in our
Exercise Sheet):

Continuing with our modeling of the Piano Manufacturer’s database, we learn that:

Ebony and Ivory (see (problem 5) above) employs piano technicians who are responsible for
inspecting the instruments before they are shipped to the customers. Each piano is inspected by at
least two technicians (identified by their employee number). For each separate inspection, the
company needs to record its date and a quality evaluation grade.

Q4. What entities and attributes do each business rule (sentence) suggest we should include in the
model?

Q5. What relationships can you identify in the statements above?

Q6. Are there any characteristics/properties of the relationship that we should consider and model?
If so, which are they?

Q7. Please draw a model of the needed database including the inferences made above (entities,
attributes, and relationships).
 E. Finalizing our model for the Piano Manufacturer’s database (Problem 7 in our
Exercise Sheet):

As we present our proposal to the board of "Ebony and Ivory”, we are informed that there are additional
considerations needed for the database. Specifically, we learn that:

The Piano technicians (see (problem 6) above) have a hierarchy of reporting relationships: some of
them have supervisory responsibilities in addition to their inspection role and have multiple other
technicians report to them. The supervisors themselves report to the chief technician of the company.

Please answer the following questions in order to add the final touches to the database model:

Q8. What entities and attributes do each business rule (sentence) suggest we should include in the
model?

Rule 1:

Rule 2:

Q9. What relationships can you identify in the statements above?

A.:

Q10. Please draw a model of the needed database including the inferences made above (entities,
attributes, and relationships).

Q11. Take the models built for the last three problems (the models made for “Ebony & Ivory”) and
combine them so that we can present the full database model to the Board of the company. Please add
your full model below: