Java Reference
In-Depth Information
The lines connecting the tables indicate relationships, where the number 1
and the infinity symbol (
) represent the cardinality of the relationships, with
infinity representing many. Each User record, with a unique userID as the
primary key, may have many (including zero or one) stock holdings, so the
userID foreign key may appear many times in the UserStocks table; in other
words, it is a one-to-many relationship. Each unique stock only has one name;
however, one stock symbol may be held by many different Users. Again, this is a
one-to-many relationship. A given symbol is unique in the Stocks table, and a
given userID is unique in the Users table because they are the primary keys of
their respective tables. They each, however, may appear multiple times in the
UserStocks table, because a given user may have many different stocks, and a
given stock may be held by many different users. The combination of a particu-
lar userID and a particular symbol in the UserStocks table must be unique,
because these two fields together represent the primary key of this table. The
UserStocks table, therefore, models a many-to-many relationship between the
Users table and Stocks table.
Figure 11-3b on the previous page displays some sample data in the data-
base. After completion of this chapter, your data should be similar.
PROGRAM IMPLEMENTATION Once the solution is designed and
validated, the next step in the development cycle is to implement the design, as
shown in Table 11-1 on page 692. For this project, in addition to new classes, the
Activator class and the various PasswordException classes previously created are
used. Because these classes require no changes for use in this project, only the
class files and not the Java source files are needed. This illustrates the reusability
of these classes, which was the intent in their design. The User class needs to be
modified significantly to contain additional information. The Password class also
could be used without modification, because no new functionality is required;
however, for objects to be stored to disk, a minor addition is necessary.
Understanding Persistent Objects
Previously, objects such as Password were used in the Java programs but were
not saved to disk. Therefore, when the programs terminated, the objects were
destroyed. Because the objects were not saved, the test program in the previous
chapter required the addition of a user before that user could log on to use the
program. Obviously, this is acceptable only in a test program. In a realistic appli-
cation, data as objects should exist beyond the lifetime of the application.
Achieving this requires the ability to save an object to permanent storage.
Saving an object to nonvolatile storage, such as a floppy disk or hard drive,
and making it available for later use implies saving the current state of the object
before the program terminates. The state of an object is the value of its attrib-
utes, or variables, at a given point in time. If there were no concern about saving
the state of the object, then you could create a new object each time the program
executes, as was done previously. Persistence is the ability of an object, including
its state, to be saved over time, allowing the object to be restored later. Imple-
menting persistence for an object, however, is different than simply saving some
data to a disk file.
Search WWH ::




Custom Search