Goal:

The goal of this project is to provide a realistic experience in the conceptual design, logical design,
implementation, operation, and maintenance of a relational database and associated applications.
First, I shall describe the application, then the categories of requirements, and then some
suggestions on how deeply you need to go in each category. A real project of this sort would require
a substantial development team working for several months (or more).

You will do this alone over several weeks. I have chosen to go with individual rather than group
projects because the goal of this project is for you to gain a personal appreciation of the depth and
breadth of issues that go into the design of a database application, rather than to have you
specialize in just one aspect (and rely on others for the rest).

The project can go well beyond the minimal requirements I outline at the end. I encourage such
extensions. They could turn into a senior design project or other independent work.

The description given here of the enterprise you are modeling is necessarily somewhat vague and
incomplete. This is by design in real life, your customers are managers in the enterprise whose
degree of computer literacy is, to put it kindly, variable.

You will need to fill in the holes in this document in create a precise design and concrete
implementation of the interfaces and applications using the database.

The checkpoints specified for the project are designed to help you get some feedback along the
way.

Enterprise description:

The enterprise is a retailer, such as a department store, discount store, supermarket, convenience
store, etc.; each of you will choose a specific retailer (either use a real one as your model or a
made-up one). To keep the project within bounds, we'll ignore issues of employees, corporate
finance, etc., and focus on the retail sales activities.

Your retailer sells a large variety of products at multiple stores. Not all products are at all stores.
Pricing may be different at different stores. Each store has its own inventory of products and needs
to decide when to reorder and in what quantity. Customers may identify themselves by joining your
frequent-shopper program. Others may remain anonymous. Your retailer has a Web site that
accepts orders. From a database perspective it is just a special store that has no physical location
and has no anonymous customers.

The database tracks inventory at each store, customer purchases (by market basket and by
customer, where possible), sales history by store, etc. Various user interfaces and applications
access the database to record sales, initiate reorders, process new orders that arrive, etc.

• The enterprise:
You may pick the enterprise that you will model. I'd like to see a wide variety chosen, so here
is a list to serve as starting point to give you ideas, but other choices are welcome, indeed
encouraged: https://en.wikipedia.org/wiki/List_of_supermarket_chains_in_the_Philippines
 • products: Products come in a variety of sizes or means of packaging. Each product has its
own UPC code (the bar code that is scanned at the checkout).
• brands: A variety of products may be sold under the same brand (e.g. Pepsi and diet Pepsi).
For such applications as reorder, specific products and sizes matter. For other applications,
data may be aggregated by brand.
• product types: A particular type of product may be sold in a variety of sizes and a variety of
brands. For example, cola is sold under such brands as Pepsi and Coke. Product types form
a specialization/generalization hierarchy. For example, cola is a type of soda, which is a type
of beverage, which is a type of food. Some products fit into multiple categories. For
example, baking soda is a cleaner, a food (since it is used for baking), and a drug (since it
may be used an antacid), but it is not a type of soda.
• vendors: Products are sold to stores by vendors. A vendor may sell many brands (e.g.
Pepsico sells Pepsi, Tropicana, Aquafina, Gatorade, Lay's, Doritos, Quaker, and others).
• stores: Stores sell certain products, each of which has a certain inventory amount at any
point in time. Stores have locations (addresses), hours at which they are open, etc.
customers: Customers who join a frequent-shopper program provide some personal
information based on what the enterprise requests. They may refuse to provide some
information. Customers come into a store (or go online) to buy a market basket of goods.
Not only must this data be stored, but also the system must be able to handle multiple
customers buying goods at the same time.

Data Generation:

For simplicity, I will not require perfectly realistic data so that you don't have to ensure that, for
example, if you are modeling an HEB Supermarket, it really does sell Shiner Bock beer. However,
you should strive for a good degree of realism in your data (and, yes, by the way, except in dry
counties, HEB sells Shiner Bock).

Where appropriate, randomly generated data are acceptable (and a good way to avoid having lots of
data entry to do).

Note the comments on collaboration below and that sharing data with others is acceptable as long
as appropriate credit is given to your source.

Client Requests:
1. E-R Model
• Construct an E-R diagram representing the conceptual design of the database.
• Be sure to identify primary keys, relationship cardinalities, etc.
2. Relational Model
• After creating an initial relational design from your E-R design, refine it based on
o the principles of relational design (Chapter 8).
• Create the relations in Oracle database.
 • Create indices and constraints as appropriate.
• If as you refine your design, you discover flaws in the E-R design, go back and change
it (even if the earlier design passed the checkpoint.) Your final E-R design must be
consistent with your relational design.
3. Populate Relations
• Include enough data to make answers to your queries interesting and nontrivial for
test purposes.
• You may find it helpful to write a program to generate test data.
4. Queries: You should run a number of test queries to see that you have loaded your
database in the way you intended. The queries listed below are those that your clients
(managers from the retail enterprise) may find of interest. They may provide further hints
about database design, so think about them at the outset of your work on this project.
• What are the 20 top-selling products at each store?
• What are the 20 top-selling products in each state?
• What are the 5 stores with the most sales so far this year?
• In how many stores does Coke outsell Pepsi? (Or, a similar query for enterprises
that don't sell soda.)
• What are the top 3 types of product that customers buy in addition to milk? (Or
similar question for nonfood enterprises.)
5. Interfaces: There are several types of users who access the database, and several
applications that run on their own.
• The database administrator (you) may use SQL either via the command line or SQL
Developer.
• Online customers need an elegant Web interface to order products.
• Your system may generate reorders automatically using triggers. Or, you may have
an application that runs periodically to scan the database looking for items to
reorder.
• Vendors periodically query the database to check for reorder requests, which they
fill by entering into the database a shipment, a delivery date, and the reorder purchase
order or orders that are satisfied by the shipment.
• An application records the increase in inventories resulting from the arrival of a
shipment. (For simplicity here, assume that shipments arrive at the time specified
by the vendor for the shipment.)
• Each checkout register runs an application that records the items in each market-basket,
updates inventory, and gathers frequent-shopper data.

Grading:
• ER design: 20 points
• Relational design, including constraints and indices: 20 points
• Data creation: sufficient quantity, reasonable realism, sufficiently interesting: 10 points
• Web-based user interfaces, including proper features, proper updating of the database,
etc.: 50 points