On Line Bank Project: Phase II Assignment UC Berkeley Computer Science 186 Fall 2002 Introduction to Database Systems September 30, 2002

Overview of Phase II - Website Implementation This phase of the project will lead you through the steps of actually instantiating your database, and implementing a programmatic interface to it. The functions you write will interact with the database in a way that is consistent with the business requirements from Phase I. Your database will be an instance of the schema you designed in Phase I, possibly with modifications. The functions you implement will use embedded SQL to query and modify and the database. Part of the project will be graded automatically, and part will be graded in person with your TA. We will provide submission information closer to the deadline.

Make sure your code runs smoothly on EECS instructional machines (rhombus, pentagon, and torus.cs.berkeley.edu) prior to submission since ALL grading will done on those. However, since all the software is freely available, you may find it easier to develop your code/website at home or on other machines you have access to. The instructions provided are designed to work with the EECS instructional machines and may not work as smoothly elsewhere. The TAs and Professor will only support EECS instructional machines.

Steps of Phase II 1. Create PostgreSQL database (10%) 2. Implement Basic Functions (50%) 3. Implement Basic Webpage (15%) 4. Implement Decision Support (25%) 5. Prepare for Presentation 6. Submit

Please spend some time to read this assignment completely before beginning.

Create PostgreSQL Database (10%) Using the instructions online (http://inst.eecs.berkeley.edu/~cs186/doc/postgres.html), create a PostgreSQL database called fnfbc (you may use another name if you so choose). Place all your DDL commands (such as CREATE TABLE, CREATE VIEW, etc) in a file called schema.sql and import/run the commands in psql (using the \i schema.sql command from within psql).

You may use any PostgreSQL data type you want except OIDs and arrays. You may not use PostgreSQL's Inheritance and Rules support. Use other features at your own risk (i.e. no TA support or sympathy).

Insert some test data into each table. We have provided some data located at the end of this assignment. You are free to reformat/augment/adjust the data to meet your particular schema requirements. One thing you may want to do is to renumber account numbers. We will provide more information about the testing procedures and test data later.

It is useful to place the data in text files and then import the data. This way you can 'reset' your database with ease. You can either write the individual INSERT statements or use delimited files (such as comma separated files) and then use \copy to import the data. We recommend using comma separated files.

When making a comma separated file for use with PostgreSQL, each row appears on its own line, with each field separated by a comma. The order of the fields must be the same as how they were listed in the CREATE TABLE statement. If there are not enough fields in the data file, the remaining columns are set to the default value or null. For example:

CREATE TABLE import ( id int, name varchar(30), zipcode varchar(5), phonenumber varchar(12), CONSTRAINT import_pkey PRIMARY KEY(id) );

The data file (import.txt) would look like: 1,John Doe,12345,987-654-3210 2,Jane Doe,67890,123-456-7890

From within psql, you would run fnfbc=# \copy import from import.data using delimiters ','

Notice that the data file does not use quotes around strings, nor are their extra spaces between fields. Beware, blank lines are processed as insertions with default or null values for all columns. Each table must use its own data file and a separate import statement.

Implement Basic Functions (50%) Now that you have a database with some data in it, you can issue SQL statements to it through PHP (or psql for practice). We will provide an API of basic functions you must implement, along with some supplemental files. You can get a copy of the provided files from ~cs186/fnfbc/*.

• fnfbc.php is the basic API. It is designed to be included by other files that provide the web interface. You must provide implementations for all functions. DO NOT CHANGE any function declarations in this file. You may additional functions as you so desire. We will test using this API directly.

• datastruct.php contains some classes. It is designed to be included by the API. PHP does not directly support structs (as in C), so we used classes without any methods to provide the same feature/ease of use. DO NOT CHANGE any of the classes, although you may ADD methods to the classes or add additional classes if you wish. Again, we will be testing using these data structures.

Before running the code be sure to modify the constants located at the top of fnfbc.php to reflect the host/port you are running PostgreSQL on as well as the userid/password.

You can test to see if your code compiles by running: rhombus [1] ~/fnfnc > php scriptname at the command line from any x86 machine (same machines that run PostgreSQL).

To actually run your code through a web browser, place your code in your public_html directory (or subdirectory) and use a web browser to request the file. The web server will run the file through php (if and only if the file ends .php) before sending the results to you. Most of your testing will be through the web server.

Implement Basic Webpage (15%) Now that you have coded the API, it is time to link the API to webpages. We will use PHP scripts to gather input from the web and call the appropriate API functions, and display the results. Grading for this section will done during the presentation.

We do not expect complex webpages, very basic HTML will suffice. Do not do anything that requires typing URLs directly. We encourage you to avoid JavaScript or and complicated browser technology like DHTML. All pages must work with IE5. You will need to use HTML forms. We will provide one screen as an example and template for you. The remaining files we have provided are:

• findCustomer.php is designed to be used via the web using the minimal schema we have provided. It interfaces with the findCustomer() and findNextCustomer() API in fnfbc.php. This can be used as a template for other web pages and may be modified/deleted or otherwise changed as you see fit. • schema.sql contains a definition of customers for use with the provided test data and findCustomer.php. You are expected to change the schema to reflect the one you provided in Phase I with the appropriate changes. • customer.data contains test data with the following fields comma separated: taxid, last, first, address, city, state, zip, phone, password, online_enabled to match the provided schema.

To test the code we have provided: 1. Create a new database (or use an existing one) 2. Load the schema from within psql using the \i schema.sql command 3. Load the test data from within psql using the \copy customers from customer.data with delimited ',' command

4. Place the 3 PHP scripts in your public_html directory (or subdirectory) 5. Make sure you've modified the the constants in fnfbc.php to reflect your database setup 6. Via the web, access the findCustomer.php webpage, http://inst.eecs.berkeley.edu/~cs186-XX/findCustomers.php 7. Try searching for "J%" - the % sign will match any set of characters when used with the LIKE operator in SQL.

Implement Decision Support (25%) Using a database solely to record transaction information is useful and important. However, the ability to ask interesting queries over that data is even more important to businesses. Commonly referred to as decision support queries, these complex queries give CEO's and marketing staff insightful information about their business operations and allow them to tailor future offerings. Grading for this section will done during the presentation and will not utilize the provided API, so you are free to add whatever functions needed.

You will implement a total of eight decision support questions. You should have a webpage for bank managers (or combine with an existing one) that has a menu of these queries (along with boxes to input query parameters). The results should be displayed on the web as well. You can add whatever functions you need to code to support the queries.

You must support at least the following basic information queries: 1. Print out all transactions at a given branch for a given date 2. Print out all transactions for a given customer between a given range of dates

You must support at least the following statistical queries: 1. Show the total activity for each branch and type of account (checking or savings) in ascending order for a given range of dates, i.e. Savings Berkeley $4000 Checking Fremont $6000 Savings Fremont $10000 Savings Walnut Creek $15000 Checking Berkeley $20000 Checking Walnut Creek $30000 Activity is defined as the sum of the absolute value for each transaction with an account from that branch. Note transfers should be counted twice, once for each account. 2. What is average amount of money each branch has in its vault over a specified period of dates? 3. Find pairs of customers where one customer withdraws a certain amount of money and another deposits that same amount in the same day (but not a direct transfer). 4. Modify (3) such that you only show pairs where the same two accounts are involved in the 'hidden transfer' at least twice within a given number of days.

You should come up with two additional interesting queries. An interesting query is on that computes useful statistics or finds non-obvious relationships. For the purposes of this assignment an interesting query also substantially uses some combination of techniques like: • Aggregation, grouping, division • Nested subqueries (usually correlated) • Many joins (such as joining more than 3 tables) Not all queries that use aggregation are interesting, you should combine the above techniques to answer interesting queries that are not easy to write and producing interesting data.

Prepare for Presentation When you are done, take a few minutes to figure out how you will present your web site. You will have as much setup time as you need, but only 10 minutes to actually demonstrate it to your TA. Leave some time for question. You will run through your queries to show your TA that they work. Your TA will enter some random data for the queries to be sure your results are not hard coded. Your TA may also ask to see the SQL statements that are being run. To make everyone's life easier, please print out fnfbc.php and other core code files you add. Signups for time slots as well as TA assignments will be posted later.

Submit Detailed submission information will be announced sometime before the due date. It will essentially consist of all your PHP and HTML files. We recommend that after you submit not to touch the files in your directory so that we can look at the time stamp and use what is already in your directory. Otherwise, we will have to reinstall your submission over the changes you made before the presentation.

Test Data This is a representation of the data we will be using to automatically test your implementations. This data is provided here as an indication of the minimal information that your database must be able to store. We will provide a script that loads this data using the API. We will then run a series of tests on this data through the API. In order to handle different schemas that you may have used, you will be allowed to write a script that will be run prior to our script that loads data to ‘setup’ the database as needed. For example, you may need to initialize branches, or other extra information.

Customers: A.J. Perlis Charles W. Bachman Edgar F. Codd 1966 Compiler Boulevard 1973 Database Avenue 1981 Relational Highway Pittsburgh, PA 15213 Minneapolis, MN 55455 San Jose, CA 95120 819-687-0502 800-113-1982 709-500-4011 PIN: 7433 PIN: 6558, Bill Payer PIN: 2890, Bill Payer

Accounts: Accounts: Accounts: 10453 Checking 85405 Savings 2% 48752 Checking 42465 Savings 2% 58120 Savings 2% 16989 Savings 2% 84422 Checking Maurice V. Wilkes Donald E. Knuth Richard M. Karp 1967 EDSCAR Lane 1974 Algorithms Bypass 1985 NP Square St. Johns, OX 99999 Stanford, CA 94305 Berkeley, CA 94720 603-160-2429 412-175-2796 331-666-0264 PIN: 3559 PIN: 2639 PIN: 7433, Bill Payer

Accounts: Accounts: Accounts: 92831 Checking 48608 Checking 48752 Checking 86421 Savings 2% 22448 Savings 2% 84422 Checking Richard Hamming John Backus James Gray 1968 Error Road 1977 FORTRAN Way 1998 Transaction Route Los Alamos, NM 87545 New York, NY 10022 Redmond, WA 98052 752-595-9637 711-146-8979 969-132-0969 PIN: 8819, Bill Payer PIN: 8034, Bill Payer PIN: 9405, Bill Payer

Accounts: Accounts: Accounts: 94810 Checking 82018 Checking 98314 Checking 16989 Savings 2% 94821 Savings 2% 94821 Savings 2% Edsger W. Dijkstra 1972 Shortest Path Austin, TX 78712 389-494-5124 PIN: 5265

Accounts: 16929 Savings 2%

Payees: ACM Membership IEEE Membership UC Berkeley 1515 Broadway 445 Hoes Lane 387 Soda Hall New York, NY 10036 Piscataway, NJ 08854 Berkeley, CA 94720 800-342-6626 732-981-0060 510-642-1042

Transactions: 8/1 – Perlis Open #10453 with $1000 8/14 – Codd Withdraw #16989 $1000 8/1 – Bachman Open #58120 with $2000 8/14 – Perlis Deposit #10453 $1000 8/1 – Wilkes Open #92831 with $1000 8/15 – Wilkes Deposit #86421 $1000 8/2 – Knuth Open #48608 with $5000 8/15 – Backus Open #82018 $5000 8/2 – Perlis Withdraw #10453 $500 8/16 – Backman Open #85405 $5000 8/5 – Knuth Check 101 #48608 $200 8/16 – Backus Deposit #82018 $5000 8/5 – Dijkstra Open #16929 with $1000 8/19 – Wilkes Check 102 #92831 $50 8/6 – Backman/Karp Open #84422 with $10000 8/19 – Gray Open #98314 $3000 8/6 – Perlis Deposit #10453 $2000 8/20 – Karp Open #84422 $200 8/7 – Perlis Open #42565 with $1000 8/21 – Karp Withdraw #48752 $500 8/7 – Hamming Open #94810 with $100 8/21 – Dijkstra Pay UCB #16929 $500 8/7 – Codd/Karp Open #48752 with $2000 8/22 – Dijkstra Withdraw #16929 $499 8/7 – Perlis Transfer #10453 #94810 $2000 8/23 – Backus Transfer #82018 #16929 $2000 8/8 – Wilkes Open #86421 with $50000 8/23 – Bachman Deposit #58120 $499 8/9 – Knuth Pay ACM #48608 $50 8/26 – Hamming Deposit #94810 $200 8/9 – Knuth Pay IEEE #48608 $100 8/27 – Knuth Pay ACM #22448 $50 8/12 – Backus/Gray Open #94821 with $4000 8/27 – Perlis Transfer #10453 #84422 $200 8/12 – Wilkes Check 101 #92831 $50 8/27 – Bachman Withdraw #58120 $2499 8/13 – Hamming Deposit #94810 $100 8/27 – Bachman Close #58120 8/14 – Codd/Hamming Open #16989 with $80000 8/28 – Gray Check 101 #98314 $1500