DOC PREVIEW
TAMU CSCE 315 - team-project-1

This preview shows page 1-2 out of 5 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 5 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CPSC 315 – Programming Studio Team Project 1: Database Implementation and Use Project Goal: Your goal in this project is in two parts. First, you are to implement a general database system with a limited amount of database functionality. You will create a standalone “library” that can be used by other programs to define, populate, and query a database. Second, you will implement a basic database application program that makes use of the database system defined. Note that in a “real” application, it is unlikely that you would implement one of these database systems “from scratch.” More likely, you would use an existing database system, and access the system via query functions, a DDL, and/or a DML. This project is meant to help you: • Understand how a database system might work at a low-level • Become familiar with the basic database operations and queries • Understand good data structure choices and algorithmic implementation of basic data structures • Become familiar with use of a version control system • Gain practice in basic modular organization and library specification Development Specifics: Your project will consist of two major pieces of code: a database library and an application module. These two pieces of code should be developed independently. That is, your database library should have an API defined for it (and the API should not expose underlying functionality unnecessarily). The library code should implement that API. Your application program should access the database only via that API. The details of the code are described below. Specification of Database Library: You should create an independent library that gets compiled into a .jar. This library should allow a user to specify a relational database, add data to the database, and perform queries on it. Specific features to be supported are given below (note: items marked with an * do not need to be completed by two-person teams): Data Definition: • Creation of tables. Users should be able to specify tables analogous to the SQL CREATE function. Attribute types to be supported are: o Integers o Floating-point numbers o Strings of variable length (you may set a reasonable maximum, e.g. 100, but the space allocated should be variable). In addition, you should enable users to specify a primary key for this data. You do not need to support weak entity sets for this program! • * Deletion of tables. Ideally, you should account for basic errors, such as specifying two tables with the same name, inserting a tuple with a duplicated key, etc. You do not need to check for more fundamental database organization problems. Data Manipulation: • Insertion of Tuples into an existing relation • * Modification of Tuples (analogous to the SQL UPDATE command) • * Deletion of Tuples (analogous to the SQL DELETE command) Note that for modification and deletion of Tuples, you should support limited conditions, as described in the querying function below. Querying: Basic SELECT-FROM-WHERE statements should be supported. These should include support for the following (all are analogous to SQL statements, but this is not saying that these functions need to be provided via an SQL-formatted query – you may choose any method you want in your API to specify the query statement, including supporting standard SQL syntax): • In the SELECT statement: o The * in the SELECT statement (i.e. select all) o * The AS command o You do not need to support operations on the items in the select statement • In the FROM statement o Up to two sources (possibly from the same relation – analogous to renamed sources in SQL) • In the WHERE clause, support for o An IN statement (applied to a table with only one attribute) o An EXISTS statement (applied to a table) o Comparisons of =, !=, >, <, >=, <= o AND, OR, and NOT o * ALL o * ANY You only need to handle cases where “full parentheses” would be used – i.e. all parentheses would be used around any statements, and will never nest more than 3 deep. For example ( ((A>B) OR (B<C)) AND (D = E) ) • Include support for SUM, COUNT, MIN, MAX on a single column of a table Note that for this program, the results of every query should be stored as a view, automatically. That is, any query that is performed should generate a new table. It should be possible to query this table by a future query, just as any of the “defined” tables. A FROM statement should be able to use one of these tables as a source, but it does have to take the query result directly (i.e. there are no nested queries, here). General Database: Commands should be included to return information about the database as a whole. At a minimum this should include • * Returning counts of total numbers of records in each table (could be done with the COUNT command mentioned earlier), or in the database as a whole. • * listing all the relations/attributes in the database Specification of Application: You should create a separate application program that uses the database API. This program should be written to handle an airline reservation system (you can assume just for one airline if you want). You will need to write routines to create the necessary tables, populate the tables (from a file and/or from user input), and query the tables in useful ways. You may make the application program as fancy as you want. But, at minimum, among the data you should keep in the database are the following: • Flight information (e.g. flight number, planes, number of passengers held, starting/ending cities, etc.) • Passenger information (e.g. Name, address, frequent flyer number if any, etc.) • Ticket/Reservation information (e.g. flight, date, passenger, cost, etc.) You should support interaction with this system, including such things as: • Find all passengers on a particular flight • Find information (including flights) for a passenger You are strongly encouraged to extend this beyond such minimal extent – e.g. supporting questions like finding out how full a particular flight tends to be, etc. Doing simply the absolute minimum would not earn a particularly good grade. However, do not overshoot, so that you are unable to get your program working – it is better to have less functionality that works than more functionality that does not. Note that any two-person team will have much lower expectations in this


View Full Document

TAMU CSCE 315 - team-project-1

Download team-project-1
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view team-project-1 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view team-project-1 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?