Solution to Course Project I

Note that there are many ways to design the database and this is only
one of them.

Pay attention to these things:

1. How to handle the inheritance relationship between Account and

StudentAccount/ProfessorAccount.

 The Relational Model has no

built-in mechanism for
specifying inheritance.
 When mapping inheritance
with a relational database,
there're usually 3
strategies. None of them is
perfect so you have to choose
the best for your needs.
 The 3 strategies are:
o Table per Hierarchy
(TPH)
o Table per Type (TPT)
o Table per Concrete
Class (TPC)
 Here is a good article
explaining the difference
between them and which
strategy to use under what
scenario: https://www.entityfr
ameworktutorial.net/code-
first/inheritance-strategy-in-
code-first.aspx (Links to an
external site.)
 o This article is written
for the Entity
Framework but applies
to any general
situation. When
reading, you can
ignore the Entity
Framework part and
focus on how each
strategy converts a
conceptual schema to
a relational schema.
 The solution below adopts the
TPH strategy, which is simple
enough and sufficient for our
use case. Other strategies also
work but you should know
their disadvantages and how
to overcome them.

2. Assignment / Submission / Comment / Grade must be designed

properly so that:

 From your design, one should

be able to
o Find out which
submission is made by
which student, to
which assignment.
o Find out which
comment is made to
which student's which
assignment, and also
who left the comment
(professor or student).
o A student can submit
multiple times to an
assignment,
 o A student should
receive only one grade
for an assignment.
 This solution introduces a
special entity
called StudentAssignment,
which represents a specific
student's actions/status
against a certain assignment.
Its mere purpose is to simplify
the design.
o Without StudentAssig
nment, you can still
design the database
but take extra caution
and make sure your
design complies with
all the requirements.

3. Roles and responsibilities of databases and applications:

 If you find it hard to

understand how databases and
applications work together,
this section might help you
clear things up.
 In a typical system that
comprises a database and an
application, the database is
responsible for storing data,
and the application is
responsible
for displaying/collecting/updati
ng/creating data, and provide
any other non-data-related
functionalities.
o Take the canvas
system as an example,
the website (server-
 side code plus front
end HTML code) acts
as the application in
this system. When
visiting canvas, the
application first
redirects you to the
login page, on which
user-inputted
username and
password
are collected and
compared with
existing records in the
database. If no record
is found or the
password doesn't
match, it will display
an error. If records
match, it will redirect
to your home page on
which your name,
profile picture, and
other personal
information
are displayed.
o If you don't have an
account already, you
can create it via the
register account page.
The application will
use a form to collect
your information
and insert a new
record to the user
table.
o If you forgot your
password, you can find
it back. The
application will
 generate a special
link, and send the link
to the email on file.
When you click the
link and reset the
password, the
application will collect
your new password
and have it updated in
the database.
 It seems that most of the work
is done by the application. But
the underlying database will
decide which functionalities
could be implemented and
which are impossible.
o For example, the
following design puts
a "sendStatus" column
in the Email table.
Thus it is possible for
the system to track
the current Email se
nd status. But, it's
impossible to track
the historical send
status. In order to
know the entire
history of all Email
delivery attempts
(timestamp, success
status, error detail), a
separate tracking
table needs to be
designed and its
relationship with the
Email table is Many to
One. This design
provides more
functionality and
 flexibility (if you don't
need the history, this
table can still store
the current status),
but the database is,
unavoidably, more
complicated.
o So in real-world
scenarios, a good
database design must
take both flexibility
and simplicity into
consideration and find
the balance point.
Over-design may bring
unnecessary
complications to the
system, and under-
design will require the
database to be re-
designed even when
the client asks for a
slight change in the
system.

Conceptual Schema:
Relational Schema: