The OER Physics Problem Database (pdb) provides an open access resource to enhance problem solving skills and student learning outcomes. The pdb is built with the open source database management system (dbms) MySQL, well known to for its reliability, functionality, and performance.
Two other main components of pdb are JabRef and LaTeX, which are both published under free software licenses. JabRef provides a graphical user interface (GUI) for users to insert questions to the pdb, and LaTeX provides a high quality PDF document output. The following flow chart shows the relationships between MySQL, JabRef, and LaTeX in handling the information in the pdb in order to produce a document of chosen physics problems.
The questions inserted into pdb with JabRef have required fields that must be completely filled in order to qualify as valid pdb input. The necessary fields are: Problem, Ndim, Owner, Timestamp, Subject, Difficulty, Solution, and Bibtexkey. LaTeX commands may be used directly in the fields; this is especially useful for the Problem and Solution inputs. Ndim is the number of dimensions of the problem, the Owner field is the user submitting this question to pdb, Subject denotes the area of physics that the question focuses on, and Difficulty should be entered in as easy, medium, or hard. Also, each question has a Timestamp field in order to make sure the problems in pdb remain current.
JabRef connects to the MySQL pdb and merges new questions with existing ones in the database. SQL is short for “Structured Query Language”, and is a standard for dbms. All information in the database is stored as tables and linked with keys, of which there is only one primary key. The primary key is a unique identification number attached to each problem in pdb. While JabRef provides a GUI interface for input, MySQL will handle the heavy lifting behind the scenes in managing the database. Such managing will be necessary as subroutines are developed to randomize and alter tables.
Figure 4: These are the tables in pdb, with a couple of rows filled. All of the question content is held in the VALUE column.
The entity relationship diagram (ERD) for pdb is shown in Figure 5. An ERD aids in visualizing the logical relationships between tables and data in a database; this also helps with design and performance. The ENTRY entity (table) holds the primary key, shown with a yellow diamond next to SHARED_ID. The dashed line linking to the FIELD entity means that there is a relationship between ENTRY and FIELD, and that FIELD contains attribute values from ENTRY. The fact that there is one, and only one ENTRY per row is shown by the two short double vertical lines on the relationship line. The pdb allows for question/answer variation, thus there may be one or many questions per unique row in entry; this is expressed as the “crow’s feet” and short vertical line next to the FIELD entity. METADATA does not relate to the other tables, but shows information about the type of data that pdb holds.
Figure 5: The erd for pdb.
In order to access particular problems from pdb, a user can search for a keyword from subject, ndim, difficulty, owner, or timestamp. For example, to select all problems that are under the subject of kinematics in pdb, the query syntax is shown in Figure 6. Note that the asterisk (*) is known as a wildcard, which returns all matches that fulfill the requirements of the given search. In this example, the subject search for all kinematic questions gives problem numbers: 1, 4, 6, 7, 9, 11.
Figure 7: The LaTeX file that will create your pdb document.
