Compare the two models for the system.
The following is the ERD for the database:
Site table is just being used as a look-up table to provide the site IDs to the system.
We have split the usual
Recorded_On column into two columns ---
Recorded_Time. This allows us to use standard user interface components for entering values for these columns. Most user interface toolkits have a date picker and a time picker, but most don't have a combined date and time picker.
Scientist_Num is being generated by the database via a sequence. You can see the code that does this in the column definition for
Scientist_Num in the
The following is the class diagram for the system that describes what the Java classes look like:
Compare this diagram with the class files in the
domain package in the NetBeans project (look in the <> folder in the project).
Take note of how the relationship between the
Scientist class is represented.
Other things to note:
Different naming conventions. Java uses camelCase (capital letters denote word boundaries) --- SQL uses Snake_Case (underscores denote word boundaries). These are industry-wide naming conventions.
There is no
Site class. The only reference to sites is the
siteId field in the
Different types. The Java classes use Java types and the database uses SQL types. In most cases there will be automatic conversion between the different representations, but in some cases we need to do some work to convert these ourselves (dates and times will require some work).
The fields in the Java classes are all
private. We have to use the
public accessor methods to get at the values of the fields. Programming languages often have encapsulation mechanisms that hide the internal details on one part of a system away from other parts of the system. Using the
private access modifier is one of the mechanisms that Java provides.
The relationship between the
Scientist is different. In the database we use a common column (
Scientist_Num) as the foreign key. In Java, the
Sample class has a field named
scientist that is a
This is the biggest difference between the two models. In object-oriented systems, relationships are implemented as fields that refer to other objects. In relational databases, relationships are implemented via common attributes (which can then be enforced via foreign keys).
These differences are referred to as the object-relational impedance mismatch. There is enough of a difference between the way object-oriented systems represent data that it is not directly compatible with the relational model. We can't just throw an object at a relational database and expect it to get saved --- the rest of this lab is about showing you what needs to be done to make this happen.