You will need to set up a database according to the design described in the "Database Design" section. Then you will need to replace some code in the Database class with JDBC code. I strongly urge you to take the time to prepare for database errors as described in the "Errors" section before writing JDBC code.
Your database should have a 3 table design:
In the score table, the user and category columns are foreign references to the id columns of the other two tables. This information is left implicit in the following diagram:
In the 3 table design, the user and category tables are entity tables. The score table is a relationship table, similar to the ownership table in the Cars example. In real world applications this kind of design makes application maintenance easier. For example, you could add new categories of trivia questions without modifying the Java or JSF page code.
For database setup you should use the procedures described in the Lab Exercise. You should start off with a sun-resources.xml file in your project setup folder.
The Cars application in the lab exercise has its own version of the sun-resources.xml file that you can access from the NetBeans "File" pane. If you don't see a "File" pane you can bring one up in the "Window" menu, or just type "2" while holding down the CTRL key. The file is in the setup folder.
Be sure to modify the sun-resources.xml file for your application. You will need to change the database name and the password. Note that the database name also appears in the URL.
Except for handling errors, your Java code modifications should be restricted to the Database class. You will need to modify the methods that access or modify user data to do database queries using JDBC. You will also need to modify the getCategoryNames() method and the part of the private addProblem() method that adds a new category name.
The Cars example provides a model for using JDBC . You should follow the example as a model. I strongly urge you to use the sql.SQL class described there. It makes writing SQL queries quite a bit easier.
Since the database access uses JDBC, all accesses can throw exceptions. You should modify the method interfaces of the database bean to throw these exceptions. Clients of the database bean need to be modified to handle the exceptions by bringing up an error page that displays the exception message. You should use Cars example as a model for doing this.
In a fully debugged application the user should never see the error page except when a database access fails due to a loss of the connection to the database. You will find, though, that the error page is useful during development. With the error page you won't have to dig through a stack trace to find out what went wrong.