Information Systems

This assignment consists of design and development of an information system. The first part of the
assignment consists of the design, which includes creating a DFD, ER diagram, mapping to the
relational schema and further normalization of the relational schema if required. The necessary
information for schema design is given in the Universe of Discourse (UoD) described below.

In the second part of the assignment, the designed schema will be implemented in MySQL. The
implementation will include creating tables, constraints, uploading or entering sample data, and
writing queries. The details are given below in the implementation section.

Universe of Discourse
Community driven repositories of data are getting increasingly popular and valuable. Wikipedia is
perhaps the most widely known example. Similar examples can be found is specific domains such as
wildlife sightings, online learning and entertainment. These repositories are supported through front-
end web enabled portals easily accessible by the wider community and back-end databases that
provide storage and retrieval functions for the data being collected. In this project, you will design and
develop a database that supports such an information system in the entertainment domain. We will
call this database SHOWTIME.

The central concept in SHOWTIME is a Show. There are three kinds of shows Movies, TV shows and
Video blogs. Each Show is identified by a unique identifier that consists of one letter indicating show
type (M: Movie, T: TV and V: Video blog), and a 7-digit sequence number. Each show is further
described by its title, a short synopsis, genre (e.g sci-fi, action, drama, comedy etc.), date of release,
language and several tags (such as superhero, aliens, magic etc.).

Users of SHOWTIME are members of the general public. They can register with their email, name, date
of birth and country of residence, and receive a unique login and password. All show entries and
updates are done by users. The users rate the shows (0-5 stars) and can also write detailed reviews.
Each review has an id, date&time and the review text. A user may write several reviews for the same
show. Other users can also write reviews. Users can rate (0-5 stars) the reviews of themselves and
others based on their assessment of the quality of the review.
For each movie and video blog, the duration is also stored. In addition, for each movie, its rating (G,
PG, M, etc.) is stored. For each TV Show, the network that aired it (e.g. Channel 10, BBC, Netflix etc.)
and the status (Current or Ended) is stored. One TV show can have many episodes. For each episode
a sequence number (1, 2, ) is known only, where the sequence number progresses irrespective of
seasons i.e. there can only one episode 1 for a given TV show. Additionally the duration of the episode,
its release date and season number is also stored.

SHOWTIME stores details of the cast and crew of all shows. Basic attributes of cast and crew members
are kept such as an internal person identifier, name, date of birth, place of birth, etc. One person can
have multiple roles in a movie e.g. Clint Eastwood is Producer and Actor for the Movie Million Dollar
Baby. Some commonly known roles can be found at https://www.themoviedb.org/movie/671-harry-
potter-and-the-philosopher-s-stone/cast. Additionally for all actors, the name of their character is also
stored. For example, Daniel Radcliffes character is Harry Potter in the movie Harry Potter and the
Philosophers Stone.
You are encouraged to review the websites www.thetvdb.com and www.themoviedb.org to get
insights into the working of such portals. You can also sample data from such sites.

1 Schema Design (PART 1)

The following describes what is expected in the design part of the assignment.

1.1 DFD and ER Diagram

Create a context level DFD. You can take your DFD to your tutorial for feedback before
starting on the ER.

Create an ER diagram using the notation taught in lectures to represent the conceptual
schema described by the Universe of Discourse. For cardinality and participation
dependencies you may use either standard notation, or the alternate (min,max) notation, but
not both. Depending on your design choices, you may need to use the extended ER diagram.

State clearly any assumptions you make regarding your design approach. Please note that you
cannot make assumption to simplify or compromise the completeness of the Universe of
Discourse. If there are any points that need clarification, in the specification of the Universe
of Discourse as given above, you must first attempt to clarify them with your tutor.

1.2 Mapping

Map the ER diagram created in 2.1 to a relational schema. Document the mapping steps. The
final schema should be given in the notation: R1 (keyattr, attr1, attr2, ). In order to identify
referential integrity constraints, be sure to either use the same names of the
referenced/referencing attributes, or write this separately e.g. R1(attr1) references
R2(somekeyattr).

1.3 Normalization

All relations resulting from the ER-Relational mapping should be normalized (if required) up
to the third normal form (3NF). For each relation given in the final schema from 2.2 show the
following

1. Identify non-obvious functional dependencies.

2. Determine if there are any partial /transitive dependencies
3. If necessary, decompose the relation to make 3NF relations
4. Clearly state the normal form of the original relation, and of the resulting relation(s).

Tip. It is likely that the relations in the schema you come up with at the end of the ER-
Relational mapping (see section 2.2) are already in #NF. However, you still need to write the
(non-trival) FDs between the attributes of each of the relations you designed, and
demonstrate that the relation is actually in 3NF by running the 3NF test on it.

Here is an example of what you may document in this part:

R1 (A, B, C, D)
FD: A A, B, C, D
No partial or transitive dependencies found, R1 is in 3NF

2 Implementation (PART 2)
The following describe the scope and requirements of the implementation in MySQL:

2.1 Tables and Constraints

Create a database in MySQL called SHOWTIME

You need to implement the final schema after your normalization in MySQL by creating the
tables and constraints. Be sure to use meaningful table and attribute names and before final
submission remove any unnecessary or temporary tables from your database. You database
should enforce basic constraints, such as:

- Referential integrity. Multiple referential integrity constraints can be extracted from

the specification.
- Domain. Attributes values are restricted to the allowed data types.
- Key and Entity integrity constraints.
- Semantic constraints if any/as given in the given Universe of Discourse.

2.2 Sample Data

Populate the database with enough meaningful sample data (at least 10 tuples per table) to
allow us to test the functionality offered by your information system. You may find some
relevant data from:

www.thetvdb.com
www.themoviedb.org
www.imdb.com
(note above are not the only sites from where such data can be found, you are free to scan
other sites)

2.3 Views

Write the following queries in SQL on your SHOWTIME databse:

a) Find users who have never written a review

b) Create a ranked list of sci-fi movies in descending order of user rating
c) What is the average rating of TV shows from BBC <or network name in your sample
data>
 d) Find the user who has rated his/her own reviews the most number of times
e) What is the longest running TV/show
f) Find the maximum rating of video blogs more than 10 minutes long
g) List all shows (title, synopsis, genre and release date) that have the tag magic
h) Who is the highest ranked reviewer
i) Which cast members have played multiple roles in shows
j) Find all shows in which Emma Watson <or a cast name from your sample data> has
played a role. List show title and role name.

Note be sure to have multiple data that can generate some result for these queries.
You will not be assessed on the correctness of the result, but on the correctness of the
query. You can build your queries progressively by building views on views.

2.3 Documenting Schema Changes

In writing your queries, you may discover some problems with your database design from
part 1. If so, in 1-2 pages, document the following:

- The original database schema from part 1

- The revised schema highlighting where the changes were made
- A short explanation as to why you needed to change the schema, e.g. which of the
above queries could not be satisfied and hence the change.

If no changes were needed then you only need to submit the original database from
part 1 in this document and a statement saying, No changes were made.

3 Submission
3.1 Guidelines for Submission of Part 1 Design:

When completed, you are to submit your DFD, ER diagram and documented steps
of the ER-to-Relational mapping process and normalisation as a hard copy.