CS 360 Final Project

1. CS 360Final Project prepared by Kirk Scott

2. General Information • You need to design, implement, and document a relational database to solve a particular informational problem of your choice. • For full credit, I am asking you to do your implementation with MySQL. • It is still possible to use another dbms and receive the vast majority of the credit. • That aspect of the project where it will make a difference is explained later on.

3. This was the book that was selected as a reference for MySQL and related technologies: • Nixon, Robin, "PHP, MySQL & JavaScript", Sebastopol, CA: O'Reilly Media, c. 2009, ISBN: 978-0-596-15713-5. • That book recommends using EasyPHP as a simple mechanism for installing a Windows, Apache, MySQL, and PHP development environment.

4. The relevant downloads and instructions can be obtained at http://easyphp.org. • You may also develop in an Apple or Linux environment if you want to, and you are not obligated to use EasyPHP if you prefer an alternative.

5. You will not have to turn in a "live" copy of your database. • You will be graded on the basis of the printed documentation you hand in. • A large share of this documentation will naturally result from the implementation.

6. You will also present the project. • As part of your presentation, you may show the live database in real time or you may show screenshots, etc. • Grading for the project will be Darwinistic. • There is no absolute standard against which it will be judged. • Your work will be evaluated in comparison with the work turned in by other students.

7. You can derive your project from any source. • You may be interested in creating a business or organizational informational scenario that is completely original. • You may also have come into contact with an informational scenario, including a relational database solution to it, through your work, an internship, another class, or some other setting. • If you don’t have an original idea and have not been exposed to an informational problem from another source, you also have the option of going to the library and looking for examples in books. • Your choice of project for this class may also overlap with your senior project.

8. Your project should consist of at least 6 related tables and no more than 10. • For people trying to come up with a project from scratch, reaching a total of 6 meaningful tables makes a suitable challenge. • For people working from something that already exists, trimming it down to a meaningful subset of no more than 10 tables makes a suitable challenge.

9. The range of 6 to 10 assures that you will be faced with design decisions that are not completely trivial while not being burdened with excessive work. • It also means that I will be evaluating projects that should be roughly comparable in size and I will be making grading decisions on quality, not quantity. • I also will not be burdened with the excessive work of trying to sort through projects with dozens of tables.

10. The materials you produce to satisfy this project should be original. • If you are working from an existing database with documentation, you will have to tailor what you hand in to the specific requirements given in this document. • It will not be acceptable to simply Xerox or print out documentation that already exists.

11. All of the textual materials should be prepared using a word processor or some other piece of software (like the dbms) which produces tabular or textual output. • Handwritten text and tables will not be accepted. • Hand drawn diagrams will be accepted if you don’t have access to a good graphical tool for drawing them. • If you hand draw them, you have to use a plastic template to make sure all of the figures and lines are nicely done.

12. Microsoft Visio is available for use on campus. • I am not an advocate of MS products, but they are the university standard, and it is possible to draw a perfectly acceptable ER diagram using Visio. • You may also create the database and then use the dbms to generate the ER diagram, assuming that the system you are using supports this capability.

13. Specific Requirements for What You Have to Hand in

14. I. Documentation of the Database Overall. • 1. One or more paragraphs of text introducing the informational scenario at hand, where it was derived from, and what purpose it serves. • 2. A brief verbal description of the entities in the informational scenario and the role they play in it. • 3. An entity-relationship model of the database which will support the scenario.

15. II. Documentation of the Tables • 4. Schemas for each table in the database. • This means a complete list of fields in each table with information about size, type, and format, whether or not nulls are allowed, and whether or not uniqueness is enforced (if they are non-key fields). • Primary key fields should be identified. • All foreign key fields in tables have to be explicitly identified. • All referential integrity support decisions have to be documented and justified. • This refers to cascading or restricting updates or deletes, for example.

16. It will be assumed that you have fully normalized your design. • If inspection reveals this not to be the case you will be penalized—unless you note in this section that you have a table that is not fully normalized and include a few written sentences along with the schema explaining what practical consideration resulted in that choice. • Note that index creation is treated separately in a later point.

17. Do not try to document the table schemas by printing out table design screen shots from MS Access, for example. • Document this by writing full SQL table creation statements for each table in the database. • If, by chance, you decide to use the command line interface for MySQL, you will have written these SQL statements and can simply print them out, whether directly or by means of a screenshot.

18. If you used a graphical user interface for MySQL and all of the design information for a table can be shown in a single screenshot, then screenshots for each table can be used for this part of the assignment. • Notice the word all.

19. The point is that all of the information for a table design is not shown in a single Access screenshot. • The list of all fields and the referential integrity decisions can't be shown at the same time, for example. • That's why it's unacceptable. • If you can't get all of the information that would be in a complete SQL create statement for a table in a single screen shot, then document this point by some other means.

20. 5. A printout of each table’s contents after being populated with sample data. • There are no specific requirements for how many sample records you should enter into each table. • In general, half a dozen would be enough. • The empirical requirement is that there be enough sample data so that the queries of point 7 and the reports of point 9, below, have results in them.

21. 6. A data dictionary. • This will consist of two parts: • A) If there are fields in different tables of the database that have the same semantic meaning and the same format, then this defines a domain. • You should list these domains along with their meaning. • For each domain you should list all of the fields in the database which are on each of these domains. • Strictly speaking, a single field also defines a domain, but it is not necessary to document these individually.

22. B) You should make a table of all of the fields in the database where you can look up which table they're in. • The same field name may occur more than once if the same name was used in different tables. • You may produce this part of the data dictionary using a word processor, but in a fully relational system a table with a name like SYSCOLUMN, which contained this information, would exist in the SYSCATALOG. • If you implement your project on such a system, all you would have to do is print this out.

23. III. Queries, Indexes, Reports, and Forms • 7. The project has to have 12 queries written in SQL. • Along with the SQL, each query should be documented by a written description of what it does or what it is good for, and its use should be illustrated with the output of the query on the sample data that the database tables have been populated with. • I only want to see the 12 most interesting queries that you can dream up against your database.

24. 8. Most systems provide indexes on the primary key field by default. • You should implement two additional indexes in your database. • Whether you used a graphical user interface to create them or not, these indexes should be documented by showing the SQL command which would create them. • You should justify these indexes by explaining which of your sample queries might have its performance improved because of the index, assuming that the tables in the database had a realistic number of records in them.

25. 9. Points 9 and 10 relate specifically to doing a Web implementation of the project. • This point refers to the matter of presenting the results of a query in a Web page. • To get full credit, the underlying query can be as simple as SELECT * FROM TableX. • In other words, this is not a test of your ability to manage a complex query. • It is simply a check to see whether you worked with other tools, like PHP, in order to see how a backend database can be connected to a Web browser front end.

26. There are various ways to set up a user interface for this—for example, it may be as simple as a hyperlink from a main page to a query result page. • In any case, if there is some sort of separate user interface page, you should provide a screenshot of it, as well as a screenshot of the page which displays the query results.

27. 10. Point 9 had to do with output. • This point has to do with using a Web form for input into a table. • This input has to be to a table involved in point 9. • To document your work for this point, you should turn in a screenshot of a browser showing a Web page containing a form, and the boxes in the form should contain input values. • You should also turn in a second screenshot generated by the query of point 9, where this screenshot differs from the screenshot of point 9 because the output has been changed by the input of point 10.

28. Information on Presentations • There will be a final project presentation of 10-15 minutes given during the class periods at the end of the semester or the final test period. • You can sign up for a time slot on the sheets taped to my office door. • During that time you should survey what you did to satisfy the ten points listed above. • You will not be graded on the presentation itself, only on the paper documentation, but you have to give a presentation in order to qualify for your paper documentation to be evaluated for credit. • The paper documentation is due no later than the end of the final test period.

29. You do not have to attend all days when presentations are scheduled. • However, at the very least, you should be there from the beginning to the end of the day when you have chosen to do your presentation. • Please do not do last minute work on your project while someone else is presenting. • Come ready at the beginning of your time period.

30. As noted earlier, grading on the projects is not based on some absolute standard, but rather, on comparison with other projects.  • Attending the presentations gives you the chance to compare what you did with what other people did.  • Sometimes students are not satisfied with their grades and they ask for a different grade after seeing what they got at the end of the semester. 

31. I will be noting attendance during the presentations.  • If you did not attend the presentations of all other students, no request to change the number of points you received on the project will be entertained.  • You may not be satisfied with the point total you received, but if you did not make the effort to inform yourself about the kinds of projects yours was being compared with, you will have no basis for thinking that the number of points you received was inappropriate. • The grading sheet is given on the next page for your reference.

32. Computer Science 360, Project Grading Sheet • Name:_____________________________________________ Total positive:________ • The comparison of projects and the allocation of points are not done on an overall basis. In order to make the grading as fair and as objective as possible, each project will be compared with the others and awarded a relative number of points in the ten different categories shown below. • Scoring Scheme: -0, -2, or -4 per heading, or -6 if completely missing. • Total positive = 100 minus total negative. • 1. Overall verbal description of project:________ • 2. Verbal description of the entities and their roles:________ • 3. An entity-relationship model:________ • 4. Table creation schemas in SQL with all constraints:________ • 5. Each table’s contents with sample data:________ • 6. Data dictionary: Domains and fields:________ • 7. 12 SQL queries with verbal descriptions and output:________ • 8. 2 index creation statements in SQL with explanations:________ • 9. Displaying query results in a Web page:________ • 10. Using a Web based form for input into a table:________ • Total negative:________

33. The End