Username and password
Each username is considered to be unique. Hence, we validate that a user
is registered by verifying the combination of the username and password.
Each and every time an action is to be performed on the database,
whether in changing or accessing user passwords, information, and
profiles, the username and password must be verified.
The username and password information needs to be built separately for
performance and implementation reasons. For performance reasons, we
need to separate the access to this information from all others to be able
to provide fast and efficient access to the data. From an implementation
point of view, we would also find it more convenient to later change
password encryption algorithms and access methods.
The user information contains information of the user's first and last
names, address, email, and so on. Once a user is registered, this
information is usually static. These data are not usually changed.
We added the date joined attribure to track when the user is registered.
The profile information reflects the user's interests in terms of categories
of redbooks. This list of categories of interest to the user may change
often, depending on the user. The list of categories may also change in
Based on the differences of the attributes, we decide to implement these
attributes in different tables.
Orders have the following attributes:
A username associated with the order
The timestamp of the order
The product that has been ordered
A unique order identification number
This unique order ID is required, as we can no longer use username as a
unique identifier (as a user can, or should be able to, order more than one
Linux Web Hosting with WebSphere, DB2, and Domino