DBMS Lab Project

Duration of the Project: 1 Month

Full Marks: 20 (for Phase I)

Phase I: Basic Individual Project (Compulsory)

Phase II: Advanced Integrated Project (Optional)

Different real life case study based projects are discussed below.

Automobile Sales Database

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.

Application description: The application is an automobile company, such as General Motors,

Ford, Toyota, or Volkswagen (or maybe a company from yesteryear like Studebaker, Hudson,
Nash, or Packard).
In our hypothetical company, it has been decided to redesign a major part of the database that
underlies company operations. Unfortunately, the manager assigned to solicit database design
proposals is not very computer literate and is unable to provide a very detailed specification at the
technical level. Fortunately, you are able to do that.
The company needs to keep quite a bit of data, but we shall focus on the following aspects of
corporate operations.

1
 • Vehicles: Each vehicle as a vehicle identification number (VIN). Lots of stuff is encoded in
real VINs (they are well described on Wikipedia), but you can just make them up if you want.
• brands: Each company may have several brands (for example, GM has Chevrolet, Pontiac,
Buick, Cadillac, GMC, Saturn, Hummer, Saab, Daewoo, Holden, Vauxhall, and Opel and
Volkswagen has Volkswagen, Audi, Lamborghini, Bentley, Bugatti, Skoda, and SEAT)
• Models: Each brand offers several models (for example, Buick’s models are the Enclave,
LaCrosse, and Lucerne, and Mercury’s models are the Mariner, Milan, Sable, and Grand
Marquis). Each model may come in a variety of body styles (4-door, wagon, etc.)
• Options: We’ll stick to color, and maybe engine and transmission.
• Dealers and customers: dealers buy vehicles from the manufacture and sell them to
customers. We’ll keep track of sales by date, brand, model, and color; and also by dealer.
This will allow us to use SQL’s OLAP tools. Note that a dealer may not sell some of the car
company’s brands. Dealer’s keep some cars in inventory. Some of course, are already sold,
but the dealer still keeps track of that fact.
• suppliers: suppliers supply certain parts for certain models
• Company-owned manufacturing plants: Some plants supply certain parts for certain models;
others do final assembly of actual cars.

• Customers: In reality, lots of demographic data are gathered. We’ll stick to name, address,
phone, gender, and annual income for individual buyers. The customer may also be a
company (e.g. Hertz, Avis, or other companies that maintain corporate fleets, but we’ll skip
that).
• We’ll skip data on corporate finance, pending bailouts, bankruptcy status etc. Not that these
data are unimportant, but we need to keep the project within bounds.

Data Generation: For simplicity, I will not require realistic data. You can just create some names
or get real ones from the car company web site.
There are many different vehicles, grouped into a variety of (possibly overlapping) cate-gories. If
you get realistic here, things get to be interesting. Thanks to “badge engineering” many vehicles
are the same except for name. That means they can be build in the same plants from the same parts
from the same suppliers. The ISA relationship will get heavy use here.

2
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 the
principles of relational design.
• Create the relations in Oracle database you used for earlier projects.
• 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 client (the manager
from the package delivery company) wants turned in. They may provide further hints about
database design, so think about them at the outset of the project.
• Show sales trends for various brands over the past 3 years, by year, month, week. Then
break these data out by gender of the buyer and then by income range.
• Suppose that it is found that transmissions made by supplier Getrag between two given
dates are defective. Find the VIN of each car containing such a transmission and the
customer to which it was sold. If your design allows, suppose the defective transmissions
all come from only one of Getrag’s plants.
• Find the top 2 brands by dollar-amount sold in the past year.
• Find the top 2 brands by unit sales in the past year.
• In what month(s) do convertibles sell best?
• Find those dealers who keep a vehicle in inventory for the longest average time.
5. Interfaces: There are several types of users who access the database. Each may need a special
application
• The database administrator (you) may use SQL either via the command line or SQL
Developer.

3
 • The vehicle locator service needs a lookup application to check inventory both locally
and at nearby dealers. This service allows a dealer to find a vehicle match the desires of
a potential customer. Marketing may want to review these inquiries to do future product
planning.
• Online customers need an elegant Web interface to find dealers and check products,
inventories, and prices. However, for this project, a command-line interface will suffice
if your Web and/or GUI skills are not up to the challenge. (After all, this is a database
course, not the Web Apps course, nor the User Interface course.)
• The marketing department needs sales reports and may want to do special data mining
and analysis. Provide them with a simple interface to generate some OLAP results.

These interfaces can be built as

• Web applications using Java applets or a scripting language.
• A standalone Java application using Swing to create a GUI
• Other GUI development tools you may know (but be sure they are platform inde-
pendent, see note below)
• Since this course is not a Java course, nor a GUI course, I will accept a simple command-
line interface. In fact, even if you are expert in GUI development, you may want to start
with a simple command-line and then upgrade later.
6. Concurrency: The company stock will go down rapidly if the database cannot support more
than one customer at a time making a purchase or if it cannot deal with more than one newly
manufactured vehicle being entered at a time. Be sure the Oracle transaction mechanism is
providing the needed guarantees.

What to turn in:

The checkpoints are meetings only; nothing needs to be turned in. Usually, I find the first
checkpoint requires some discussion, while checkpoint 2 can often be handled quickly (even via
email). Checkpoint 3 is mainly in place to ensure that the projects are on schedule (again, email
will do). Please talk to me about questions at any point; don’t wait for a checkpoint.

The final version of the project is to be turned in as a single zip file on blackboard. I will accept
paper for the ER diagram since we are not covering drawing tools for these diagrams, but
Powerpoint does work fairly well for this purpose.
1. E-R diagram, plus any explanatory notes. At minimum you must include all the entity and
relationship sets implied by this handout. You may go beyond the minimum. Remember that
the manager who defined the specifications is not computer literate so the specifications
should not be viewed as necessarily being precise and complete.
2. Relational schema. It is likely for many of you that your ER design will be sufficiently
extensive that we agree that only a part of the resulting relational design will actually

4
 be implemented under Oracle on Edgar3. This is something on which we’ll agree before
Checkpoint 2. This is the point where we cut implementation effort and data-entry time to
something realistic for the course time frame.
3. Do NOT turn in a listing of all your data. I can see them online if I find it necessary. I, as
DBA, will have access to your database online and will use that if your submission leaves me
with some unresolved questions.
4. A set of sample queries.
5. The code to implement the various interfaces. (By restricting your development to Java, your
code should be platform independent. I will accept quite basic interfaces (command line with
a modest command set), but encourage more elegant interfaces. Depending on the degree of
sophistication you plan for each interface, we can agree to fewer than the 6 interfaces
requested by the client.
6. Please avoid platform-specific solutions. It is a bit hard for me to debug custom in-stallations
in the time-frame I have to grade the projects. Please check with me before making any design
decisions that bind your application to a specific hardware or soft-ware platform.
7. A README file in the top-level folder that explains what is where, etc. Include usage
instructions for the interfaces

8. Everything should be in a single zip file so that when I unzip it, I can read the README file,
follow the directions, and run your project.

Collaboration: Your project design and interface implementation is to be your own work. You
may share data to load into your database. You may also share code that generates those data.

5
Electronics Vendor Database
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.

Application description: The application is an electronics vendor that operates both a Web site and
a chain of many physical stores. Examples include Best Buy and Circuit City. To find out more
about this application, think about any experiences you may have had making purchases both
online and in-store, and browse their Web sites.

In our hypothetical company, it has been decided to redesign a major part of the database that
underlies company operations. Unfortunately, the manager assigned to solicit database design
proposals is not very computer literate and is unable to provide a very detailed specification at the
technical level. Fortunately, you are able to do that.
Here are a few points to consider:
• There are many different products, grouped into a variety of (possibly overlapping)
categories. Groupings can by type of product (cameras, phones, etc.), by manufacturer.
• (Sony, Apple, etc.), or by other means (for example, a Gateway PC might be packaged with
a Sony monitor and an HP printer and marketed as a package).
• Some customers have a contract with the company and bill their purchases to an ac-count
number. They are billed monthly. Other customers are infrequent customers and pay with a
credit or debit card. Card information may be stored for online customers, but not for in-
store customers.
• Online sales must be sent to a shipper. The company needs to store the tracking number for
the shipping company so it can respond to customer inquiries.

• Inventory must be accurate both in stores and in warehouses used to replenish stores and to
ship to online customers. When inventory is low, a reorder should be sent to the manufacturer
and listed in the database. When goods arrive, inventory should be updated and reorders
marked as having been filled.

• Sales data are important for corporate planning. Marketers may want to look at sales data by
time period, product, product grouping, season, region (for stores), etc.

6
Client Requests:
6. E-R Model

• Construct an E-R diagram representing the conceptual design of the database.

• Be sure to identify primary keys, relationship cardinalities, etc.

7. Relational Model

• After creating an initial relational design from your E-R design, refine it based on the
principles of relational design.
• Create the relations in Oracle database you used for earlier projects.
• 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.

8. 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.

9. 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 client (the manager
from the package delivery company) wants turned in. They may provide further hints about
database design, so think about them at the outset of the project.

7
 Assume the package shipped by USPS with tracking number 123456 is reported
to have been destroyed in an accident. Find the contact information for the
customer. Also, find the contents of that shipment and create a new shipment of
replacement items.
Find the customer who has bought the most (by price) in the past year.
Find the top 2 products by dollar-amount sold in the past year.
Find the top 2 products by unit sales in the past year.
Find those products that are out-of-stock at every store in California.
Find those packages that were not delivered within the promised time.
Generate the bill for each customer for the past month.

• Interfaces: There are several types of users who access the database. Each may need a special
application

The database administrator (you) may use SQL either via the command line or
SQL Developer.

Customer service needs a lookup application to check inventory both locally and
at nearby stores.

Online customers need an elegant Web interface. (depending on your skill with
applets, they may or may not get this.)

Call center staff need an application that allows quick access to customer data
and the ability quickly to enter phone orders.

The stocking clerks at the warehouses need an application to help them record
incoming shipments and update inventory

The marketing department needs sales reports and may want to do special data
mining and analysis. Because we do not cover these topics until late in the
course, these features may be left to version 2, planned for the year after you
graduate Lehigh.
These interfaces may, in some cases, use existing Oracle tools, in which case all you need
to provide are instructions. In other cases, the target user of the interface is not someone we
would expect to be fluent in SQL. Those interfaces can be built as
• Web applications using Java applets or a scripting language.
• A standalone Java application using Swing to create a GUI .
• Other GUI development tools you may know (but be sure they are platform
independent, see note below)

8
 Since this course is not a Java course, nor a GUI course, I will accept a simple
command-line interface. In fact, even if you are expert in GUI development, you
may want to start with a simple command-line and then upgrade later.

3. Concurrency: The company stock will go down rapidly if the database cannot support more
than one customer at a time making a purchase. Be sure the Oracle transaction mechanism
is providing the needed guarantees.

What to turn in and how much I actually expect you to do:

The checkpoints are meetings only; nothing needs to be turned in. Usually, I find the first
checkpoint requires some discussion, while checkpoint 2 can often be handled quickly (even via
email). Checkpoint 3 is mainly in place to ensure that the projects are on schedule (again, email
will do). Please talk to me about questions at any point; don’t wait for a checkpoint.
The final version of the project is to be turned in as a single zip file on blackboard. I will accept
paper for the ER diagram since we are not covering drawing tools for these diagrams.
I, as DBA, will have access to your database online and will use that if your submission leaves
me with some unresolved questions.
1. E-R diagram, plus any explanatory notes. At minimum you must include all the entity and
relationship sets implied by this handout. You may go beyond the minimum. Remember that
the manager who defined the specifications is not computer literate so the specifications
should not be viewed as necessarily being precise and complete.

2. Relational schema. It is likely for many of you that your ER design will be suffciently
extensive that we agree that only a part of the resulting relational design will actually be
implemented under Oracle on Edgar3. This is something on which we’ll agree before
Checkpoint 2. This is the point where we cut implementation effort and data-entry time to
something realistic for the course time frame. You may share data with your classmates but
not design nor code (SQL, Java or anything else) provided you credit your source.
3. Do NOT turn in a listing of all your data. I can see them online if I find it necessary.
4. A set of sample queries.
5. The code to implement the various interfaces. (By restricting your development to Java, your
code should be platform independent. Please discuss any non-platform independent
strategies before you implement them.) I will accept quite basic interfaces (command line
with a modest command set), but encourage more elegant interfaces. Depending on the
degree of sophistication you plan for each interface, we can agree to fewer than the 6
interfaces requested by the client.

6. A README file in the top-level folder that explains what is where, etc. Include usage
instruction.

9
 Retailer Database

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.

If you complete the project by the early deadline, you may move on to a second, collaborative
phase of the project in which I will ask groups of you to integrate your databases into a unified
distributed system.
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.

10
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: Walmart, Target, J.C. Penny, Sears, Costco, BJ's, Best
Buy, American Eagle, Nordstrom, Safeway, Aldi, Albertsons, Acme, HEB, Food Lion,
Piggly Wiggly, Wegmans, Walgreens, Rite Aid, CVS, Longs, Superfresh, Carrefour,
Tengelmann, Hankyu, Dillards, Wawa, Sheetz, Modells, Petsmart, RadioShack. I've
included some non-US enterprises on this list and encourage you to consider them, or other
non-US retailers.
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
an 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 t 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.

11
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, re ne it based on
the principles of relational design.

 Create the relations in Oracle database.

 Create indices and constraints as appropriate.

 If as you re ne your design, you discover flaws in the E-R design, go back and
change it (even if the earlier design passed the checkpoint.) Your functional 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 nd of interest. They may provide further hints about database design, so
think about them at the outset of your work on this project.

12
  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.
 Markets run various OLAP queries.
 Online customers need an elegant Web interface to order products. However, for this
project, a command-line interface will suffice if your Web and/or GUI skills are not up
to the challenge. (After all, this is a database course, not the Web Apps course, nor the
User Interface course.)
 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 ll 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 speci ed by the
vendor for the shipment.)

 Each checkout register runs an application that records the items in each market-basket.

13
 These interfaces can be built as
 Web applications using Java applets or a scripting language.
 A standalone Java application using Swing to create a GUI
 Other GUI development tools you may know (but be sure they are
platform independent, see note below)
 Since this course is not a Java course, nor a GUI course, I will
accept a simple command-line interface. In fact, even if you are
expert in GUI development, you may want to start with a simple
command-line and then upgrade later.

6. Concurrency: The company stock will go down rapidly if the database cannot support more
than one customer at a time making a purchase or if it cannot deal with more than one item
being reordered. Be sure the Oracle transaction mechanism is providing the needed
guarantees. By running the various queries and applications in separate sessions (you can run
multiple JBDC connections at once), you can simulate the real-life operation of your
enterprise. Test concurrency carefully: don't re up several processes that submit customer
market baskets until you are sure things work (and don't scale this up to hundreds of
customers or the system is likely to crash or bog down { it is only a P4 with 4GB of memory!)

Logistics:
I find it very important to discuss your ER design with you. During the week of Feb 16, I will
allocate a substantial block of time for 15 minute meetings. There are currently 43 students total
in 241 and 341, so it will be a challenge to get everyone scheduled. I will have sign-ups in advance
for specific time slots and will try to stay on schedule to avoid queuing. Of course, we can schedule
additional meetings as needed. It is important to be well prepared for the checkpoint 1 meeting and
to have a copy of your ER diagram that you can leave with me.

The choice of doing the second phase of the project is up to you. I realize that some of you are
taking several project courses and may need to scale back a bit, but for those who can participate,
phase 2 will show you the challenges of a more realistic database scenario. The groups for data
integration will not be determined until the dates listed. This will avoid the unrealistic scenario of
a group designing in-advance for the data integration.

What to turn in:

14
The checkpoints are not graded. Usually, I find the first checkpoint requires some dis-cussion,
while checkpoint 2 can often be handled quickly (even via email). Checkpoint 3 is mainly in place
to ensure that the projects are on schedule (again, email will do). Please talk to me about questions
at any point; don't wait for a checkpoint.

The final version of the project is to be turned in as a single zip le on coursesite. I will accept paper
for the ER diagram since we are not covering drawing tools for these diagrams, but Powerpoint
does work fairly well for this purpose.

1. E-R diagram, plus any explanatory notes. At minimum you must include all the entity and
relationship sets implied by this handout. You may go beyond the minimum. Remember that
the manager who defined the specifications is not computer literate so the specifications
should not be viewed as necessarily being precise and complete.
2. Relational schema. It is likely for many of you that your ER design will be sufficiently
extensive that we agree that only a part of the resulting relational design will actually be
implemented under Oracle on Edgar3. This is something on which we'll agree before
Checkpoint 2. This is the point where we cut implementation e ort and data-entry time to
something realistic for the course time frame.
3. Do NOT turn in a listing of all your data. I can see them online if I nd it necessary. I, as DBA,
will have access to your database online and will use that if your submission leaves me with
some unresolved questions.
4. A set of sample queries.
5. The code to implement the various interfaces. (By restricting your development to Java, your
code should be platform independent. I will accept quite basic interfaces (command line with
a modest command set), but encourage more elegant interfaces. Depending on the degree of
sophistication you plan for each interface, we can agree to fewer than the 7 interfaces
requested by the client.

6. Please avoid platform-specific solutions. It is a bit hard for me to debug custom installations
in the time-frame I have to grade the projects. Please check with me before making any design
decisions that bind your application to a speci c hardware or software platform. Platform-
specific solutions will become a nightmare in the data-integration phase.
Please submit your java code as .java les that I can compile and run. Please do not submit
them embedded in a NetBeans project or any other IDE.
7. A README le in the top-level folder that explains what is where, etc. Include usage
instructions for the interfaces
8. Everything should be in a single zip le so that when I unzip it, I can read the README le,
follow the directions, and run your project.

15
Grading:
I shall use the following approximate template for grading:

1. ER design: 20 points
2. Relational design, including constraints and indices: 20 points
3. Data creation: sufficient quantity, reasonable realism, interesting": 10 points
4. User interfaces, including proper features, proper updating of the database, etc.: 30 points
5. Concurrent operation of interfaces: 10 points
6. I reserve the right to give extra points for exception solutions to parts of the project.
7. Phase 2: 10 points.

Collaboration:
Phase 1: Your project design and interface implementation is to be your own work.
You may share data to load into your database. You may also share code that generates
those data. Please credit your source in each such case.
Phase 2: If you go on to phase 2, your designated team's work must be its own. Your team
will receive a single grade on this phase on the assumption that everyone contributed
equally to the data-integration work. Your team may submit a request for a different
allocation of credit. Any issues in effective team collaboration should be resolved within
the team if possible (that's the best \real-world" first step) and referred to me if attempted
resolution.

16