CS 4250: Project Part 1
Hardcopy (submitted during class time only) or email due by 5 pm on Tuesday,
February 6, 2018. (Email must be plain text, MS Word, or PDF,
with subject line "cs4250 project part 1". The email should be carbon-copied to all
project partners, for future reference. Do not compress the file.)
- Form a team of 2-3 people and decide on a group name. Decide on a
good application for your database. Read the
Project Overview for project ideas.
- When forming your groups, it would be wise to discuss
when and where group members are available to meet. Selecting groups
so that all members have overlapping free time in the members' weekly
schedules will be helpful when students need to meet for group work.
- I prefer that no groups attempt exactly the same project.
(Do not concern yourself too much with this restriction; I will help you tweak
the project plans to clear up any potential conflicts.)
- To facilitate constructive group work, you should consult the
strategies for teams: Team member handbook" by Kennedy and Nilson (3.2 MB).
- (20 points) Write a two page project proposal / description in the
(i) Name of the project. Full names and email
addresses of the students in the group.
(ii) The domain of your database application.
(iii) The intended user group for your database application.
(iv) What will be modelled by your system (and what will not)?
(v) Pages 40-41 in the
"Successful strategies for teams: Team member handbook"
discusses, among other important ideas, the importance of forming ground
rules for a working group, and provides some samples of possible group rules.
Discuss ground rules with your group, and include five or more ground rules
your group agrees on in your project proposal.
(vi) What other
"value-added" facilities could your system support (but that
you will not build explicitly)? The goal is for us to mutually agree on
a project that is feasible over the course of one semester. If you have
questions, meet the instructor during office hours.
Yes, correct English grammar counts, in this document and always. Complete
English sentences are expected, grammatically correct and meaningful.
Wise Idea: Pick a domain for your database application that all members
of the group understand reasonably well. If only one member of a group
understands the data domain, and that member catches smallpox at an
inconvenient time, completing homework assignments satisfactorily will
Frequently Asked Questions
- Since this is a preliminary project proposal, how can we be sure
what the role of each project member will be? How much detail should we include
on this in our writeup?
Answer: You don't have to
"commit" to anything now; what we are looking for in this question is to
see if any of the group members brings special talents / experiences to
bear upon the project. For example, if you are building a medical
database and there is a student from the nursing department in your
group, (s)he can help identify bad design choices from a nursing point
of view. If one of you has experience in web-based software development,
then that would be a good thing to mention.
- We want our users to do this and have a drop-down menu on the right and to be using a smartphone and ...
Answer: Tough luck. A database stores information, somewhat like a
library. What users of your database choose to build on top of your database
-- the devices they support, the layout of the user interfaces -- is entirely
up to your users. Your database simply makes data available to aid them,
as our campus library makes books available to students.
- "User group"? Huh?
Answer: Knowing who will be using your database application will
guide decisions about what data will be modelled by the system and what
will not. For example, if your project domain is "data about refrigerators,"
a user group of "people shopping for appliances" will want
very different data when compared to a user group of "engineers designing and
building new refrigerators."
"Everybody" is absolutely NOT an acceptable answer to this question.
You group needs to have a clear idea of who you are designing the database for,
before you begin design work.
- Do we have to draw an E/R modelling diagram for our
Answer: No. I just need an English
document that says what you will do and some details of what the
functionality of the final system is.
- Can you explain what you mean by "value-added facilities"?
Answer: For example, in
the movies domain, this would mean the "recommender system" that makes
selections of movies for potential customers based on buying trends. In
other words, the recommender system is a tool or service customers might like,
which would be relatively easy to build if a movie database system existed,
and difficult to build if no movie database system existed.
This question is intended to set
you thinking in larger-scope, out-of-the-box, and to make you explain
potential advantages of your database from a user point of view. If you are
an IT person for a corporate organization, you will frequently need to
"justify" investing extra resources into developing something like a
database/web-system, etc. One way to do that is for you to think of what
kinds of applications a database can "enable."
- In the
part, "what will be modelled (and what will not)", what do you expect us
Answer: For example, in the movies domain,
you can write something like "We will model movies, actors, producers
and studios" but not "reviews, movie theaters and sales figures." This way all
of us are clear on what will be the final outcome.
This proposal is written for your (fictional) business manager, and should
not include techno-babble about primary keys or domain data types. What your
group submits should be a proposal that will not change over the whole
semester, regardless of what changes to the relational design of your database
your group makes later on.
- We want to create the database for famous-company-X. Can we?
Answer: Do not violate trademarks or copyrights. Make up
a new company of your own that is in the same area of business of famous-company-X,
and propose building the database for your own (fictional) company.