Database Systems

Project Suggestions

These suggestions are intended to help give you ideas for how to get started with your project proposal. These suggestions do not themselves meet the proposal requirements given in the project specifications that will appear on the web! You are expected to modify and customize from here to result in a project proposal that does meet those requirements.

The first suggestion is to select/devise a scenario of interest to you. If you have particular expertise with your chosen scenario, so much the better. You will be spending quite a bit of time this semester on this project, and such interest/expertise can make it easier to do so. Note, also, that a scenario that you understand will likely be easier to model than one you do not (but some scenarios are inherently ... "interesting" to model, regardless.)

Here are some "classical" categories for database project scenarios --- you are not limited to these, by any means, but reading over them might help you to come up with an idea for your project proposal. Some outstanding past projects that I can think of do not fit in any of these categories --- but other outstanding ones have been firmly in a category below.

Personal-hobby-related

you have a lending library of comic books, cd's, science fiction books, etc.

1. you are having trouble keeping track of who is borrowing what, or what copies of what work you have in what condition.

2. you would like to be able to organize items in a variety of ways, perhaps on a whim.

1. Who is currently borrowing work X?

2. Which works by Y do I have?

a report listing what each person has borrowed, in alphabetical order by person, with the works borrowed by each person in alphabetical order by title.

advantages that leap to mind:

You already have expertise in the area. and

You may even have a vested interest already in developing a database for the scenario

possible pitfalls:

The major pitfall here is that, if the hobby is essentially a collection whose contents you wish to store in a database, the resulting database may have too simple a structure to be suitable for a CS 377 project. Part of the purpose of the project is to give you practice dealing with database modelling and design, and even if your collection contains thousands of items, it may still boil down to only one or two categories of items. Note that a category that contains subcategories is likely to "count" as only one entity of the five that will eventually be required (as a minimum) in your project model.

It is also worth noting that the difference between an entity, and a characteristic of an entity (an attribute), can be a particular issue here. Is the author or singer of a work an entity? If so, it should have other important characteristics besides his/her name (an entity generally should have several characteristics/attributes...), and it should itself be related to some other entity or entities.

Sports-related

for example:

a sports league --- be it baseball, football, softball, soccer, etc. This could be at the professional or college or amateur levels.

a sports club, especially one that organizes and/or participates in tournaments, loans equipment, schedules games/matches, etc.

example of a typical problem within such a scenario:

keeping track of players, various player or team statistics, which team is playing where when, who is supposed to officiate which matches, etc

example of a typical question a user might ask:

for what team does player X play?

example of a typical report:

a report showing the top player in a particular statistic from each team, ordered from best in that statistic on down.

advantages that leap to mind:

It is usually easy to come up with example data, to come up with questions someone within the scenario might want to ask, and to come up with example reports.

possible pitfalls:

The concepts of "game" and/or "match" are likely to be more complex to model than you might suspect. Likewise, if statistics play a role (as they often do in sports), modelling these can also be trickier than you might suspect.

Be careful to define the scope of your scenario specifically, and to also specify who the principal users in the scenario are.

Avoid the temptation to enter huge quantities of "real" data, just because it is readily available --- remember, the project's goal is to develop and implement a demonstrable prototype.

Be careful to distinguish between what needs to be stored, and what can be computed if you have stored the appropriate raw data.

Tournament-related:

for example:

(yes, this might be related to the previous category...)

a club whose activities include attending and/or organizing tournaments of any kind that you can imagine --- fencing, bridge, academic competition, rugby, chess, gymnastics, etc.

can be on a "higher" level --- a regional fencing organization that keeps track of multiple tournament results for multiple clubs --- or "lower" level --- all the details required for a single academic (such as College Bowl or Quiz Bowl) tournament, including what teams attended, what players were on each team, what games occurred, who officiates each match, etc.

example of a typical problem within such a scenario:

keeping track of who has already played who, and when.

example of a typical question a user might ask:

What were the scores of all the matches that X played in?

example of a typical report:

A schedule, in chronological order, showing who is playing who, where, and when.

advantages that leap to mind:

Especially if teams involving multiple people are involved, it is usually not hard to devise a scenario including at least five distinct entities.

possible pitfalls:

as mentioned in the sports-related section, the concepts of "game" and/or "match" are likely to be more complex to model than you might suspect. Likewise, if statistics play a role, modelling these can also be trickier than you might suspect.

Be careful to distinguish between what needs to be stored, and what can be computed if you have stored the appropriate raw data.

Retail-Business-related

for example:

a clothing store, a food store, etc.

example of a typical problem within such a scenario:

keeping track of inventory, of employee hours, of customer special orders, etc.

example of a typical question a user might ask:

How many of item X do we currently have in stock?

example of a typical report:

A listing of the current inventory, organized by category, in reverse order of quantity of each item.

advantages that leap to mind:

Relatively easy to understand/imagine.

Quite practical.

possible pitfalls:

In these scenarios, it is quite likely that inventory will turn out to be a supertype entity, with different types of inventory as subtype entities. These, altogether, will count as a single entity when seeing if your project has at least the minimum required number of entities.

Be careful to distinguish between what needs to be stored, and what can be computed if you have stored the appropriate raw data. (A report does not necessarily correspond to a database entity!)

Handling employee time schedules can be tricky.

Service-based-business-related

for example:

a catering business, a doctor's or vet's office, a repair business.

example of a typical problem within such a scenario:

keeping track of appointments or bookings, keeping track of a patient's/customer's history.

example of a typical question a user might ask:

What are our bookings/appointments for today/a particular date?

example of a typical report:

for each customer, what repairs have been done/appointments has he/she had, in chronological order.

advantages that leap to mind:

Relatively easy to understand/imagine.

possible pitfalls:

Temporal issues of appointments can be tricky (as can handling employee time schedules, if  applicable).

May be slightly more likely to have a person-related supertype/subtype situation.

Non-profit-organization-related

for example:

creating a database for dealing with day-to-day issues of a philanthropic organization.

example of a typical problem within such a scenario:

keeping track of who volunteers when, the status of current projects, and donations.

example of a typical question a user might ask:

Who was our most generous donor in the past 6 months?

example of a typical report:

An alphabetical list of current projects and who is volunteering for each of them (in alphabetical order of last name within each project).

advantages that leap to mind:

relatively easy to imagine converting this for actual use by a local organization, perhaps.

possible pitfalls:

May be slightly more likely to have a person-related supertype/subtype situation.

Modelling donors and volunteers, if applicable, can be tricky.

Lesson/Course-related

for example:

the activities of an organization, or of a small group of individuals (or a business) offering courses (in some sport, for example, or dog training classes, or skiing lessons, etc.)

example of a typical problem within such a scenario:

keeping track of which lessons/courses still have openings, or what the prerequisites are for a particular course.

example of a typical question a user might ask:

Are there still any openings in the coming semester's Tuesday-Thursday section/offering of course X?

example of a typical report:

list the courses in alphabetical order, listing the current enrollees in each in alphabetical order by last name.

advantages that leap to mind:

as a student, you may already be able to guess how a database could be useful in such a scenario. (Be careful, however --- these can be tricky to model; see below.)

possible pitfalls:

Beware of the difference between a course, and a particular offering of that course. (They are not the same entity...)

Consider: does your scenario include just the "current" offerings, or do you want it to "carry over" over time (over multiple "semesters", for example)?

Song/Music-related

(this is often related to one of the previous categories, as well)

for example:

maintaining a musical recording library, or a recording studio, or the affairs of a musical band or bands.

example of a typical problem within such a scenario:

keeping track of who is currently borrowing a particular album, or which bands have reserved which recording studios when, or when the band is performing in which locations.

example of a typical question a user might ask:

Which artists have recorded versions of a particular song?

example of a typical report:

List, for each band (in alphabetical order by band), their coming concerts, in chronological order.

advantages that leap to mind:

if you are musically inclined, you may already have an interest in such a project.

possible pitfalls:

A project making a database of your CD collection is, quite likely, not going to be structurally complex enough to serve as a CS 377 project. (It can be hard to reach the requirement of at least 5 distinct, substantial, not-counting-subypes entities.) Note that the above possibilities thus go a bit further, also involving loans of recordings (and thus who is borrowing them, also), which bands are recording what in what studios, what concerts are occurring when, etc.

It can be trickier to model the concepts related to musical albums than you might suspect. (Consider singles vs. EP's vs. compilation albums vs. movie soundtracks...) You also need to be careful about the distinction between a song, and a particular recording of that song.

It is also worth noting that the difference between an entity, and a characteristic of an entity (an attribute), can be a particular issue here. Is the group who recorded a song an entity? How about the author of a song? If so, it should have other important characteristics besides his/her/its name (an entity generally should have several characteristics/attributes...), and it should itself be related to some other entity or entities.

Movie/Video-related

(this is often related to one of the previous categories, as well)

for example:

a "video" store is the classic scenario, here, although it is not the only possibility.

example of a typical problem within such a scenario:

keeping track of all of the copies and formats of different movies (which are currently rented? which are overdue? which need repair or cleaning? which are available in DVD?)

example of a typical question a user might ask:

Are there currently any unrented DVD's of movie X?

example of a typical report:

List the most-rented movie titles of the past month, most-rented first.

advantages that leap to mind:

relatively easy to see how a database might be helpful (although, beware --- it can be trickier to actually model than you might think. See below.)

possible pitfalls:

See the comment under the Song/Music-related category. Likewise, a database of one's movie or video collection is unlikely, by itself, to be structurally complex enough to serve as a CS 377 project. A video store, a video library where loans are tracked, etc., are examples of more feasible options.

A classic oversight is to not note the difference between a movie, and a particular recording of a movie.

Beware ---  a person-related supertype/subtype situation may very well arise when you try to model actors, directors, etc.

It is also worth noting that the difference between an entity, and a characteristic of an entity (an attribute), can be a particular issue here. Is the director who directed a movie an entity? If so, it should have other important characteristics besides his/her name (an entity generally should have several characteristics/attributes...), and it should itself be related to some other entity or entities.