Professional Documents
Culture Documents
4. What is Action Class? - The Action Class is part of the Model and is a wrapper around
the business logic. The purpose of Action Class is to translate the HttpServletRequest to
the business logic. To use the Action, we need to Subclass and overwrite the execute()
method. In the Action Class all the database/business processing are done. It is
advisable to perform all the database related stuffs in the Action Class. The
ActionServlet (commad) passes the parameterized class to Action Form using the
execute() method. The return type of the execute method is ActionForward which is
used by the Struts Framework to forward the request to the file as per the value of the
returned ActionForward object.
5. Write code of any Action Class? - Here is the code of Action Class that returns the
ActionForward object.
6. import javax.servlet.http.HttpServletRequest;
7. import javax.servlet.http.HttpServletResponse;
8. import org.apache.struts.action.Action;
9. import org.apache.struts.action.ActionForm;
10. import org.apache.struts.action.ActionForward;
11. import org.apache.struts.action.ActionMapping;
12.
13.public class TestAction extends Action
14.{
15. public ActionForward execute(
16. ActionMapping mapping,
17. ActionForm form,
18. HttpServletRequest request,
19. HttpServletResponse response) throws Exception
20. {
21. return mapping.findForward(\"testAction\");
22. }
23. }
24. What is ActionForm? - An ActionForm is a JavaBean that extends
org.apache.struts.action.ActionForm. ActionForm maintains the session state for web
application and the ActionForm object is automatically populated on the server side
with data entered from a form on the client side.
25. What is Struts Validator Framework? - Struts Framework provides the functionality
to validate the form data. It can be use to validate the data on the users browser as well
as on the server side. Struts Framework emits the java scripts and it can be used
validate the form data on the client browser. Server side validation of form can be
accomplished by sub classing your From Bean with DynaValidatorForm class. The
Validator framework was developed by David Winterfeldt as third-party add-on to
Struts. Now the Validator framework is a part of Jakarta Commons project and it can be
used with or without Struts. The Validator framework comes integrated with the Struts
Framework and can be used without doing any extra settings.
26. Give the Details of XML files used in Validator Framework? - The Validator
Framework uses two XML configuration files validator-rules.xml and validation.xml.
The validator-rules.xml defines the standard validation routines, these are reusable and
used in validation.xml. to define the form specific validations. The validation.xml
defines the validations applied to a form bean.
27. How you will display validation fail errors on jsp page? - The following tag displays
all the errors:
<html:errors/>
28. How you will enable front-end validation based on the xml in validation.xml? - The
<html:javascript> tag to allow front-end validation based on the xml in
validation.xml. For example the code: <html:javascript formName=”logonForm”
dynamicJavascript=”true” staticJavascript=”true” /> generates the client side java
script for the form “logonForm” as defined in the validation.xml file. The
<html:javascript> when added in the jsp file generates the client site validation script.
^Back to Top
^Back to Top
^Back to Top
In the original member list, each member name is followed by any databases that the member
has experience with. Some might know many, and others might not know any. To answer the
question, "Who knows DB2?" we need to perform an awkward scan of the list looking for
references to DB2. This is inefficient and an extremely untidy way to store information.
Moving the known databases into a seperate table helps a lot. Separating the repeating groups
of databases from the member information results in first normal form. The MemberID in the
database table matches the primary key in the member table, providing a foreign key for
relating the two tables with a join operation. Now we can answer the question by looking in the
database table for "DB2" and getting the list of members.
In the Database Table, the primary key is made up of the MemberID and the DatabaseID. This
makes sense for other attributes like "Where Learned" and "Skill Level" attributes, since they
will be different for every member/database combination. But the database name depends only
on the DatabaseID. The same database name will appear redundantly every time its associated
ID appears in the Database Table.
Suppose you want to reclassify a database - give it a different DatabaseID. The change has to
be made for every member that lists that database! If you miss some, you'll have several
members with the same database under different IDs. This is an update anomaly.
Or suppose the last member listing a particular database leaves the group. His records will be
removed from the system, and the database will not be stored anywhere! This is a delete
anomaly. To avoid these problems, we need second normal form.
To achieve this, separate the attributes depending on both parts of the key from those
depending only on the DatabaseID. This results in two tables: "Database" which gives the
name for each DatabaseID, and "MemberDatabase" which lists the databases for each member.
Now we can reclassify a database in a single operation: look up the DatabaseID in the
"Database" table and change its name. The result will instantly be available throughout the
application.
The Member table satisfies first normal form - it contains no repeating groups. It satisfies
second normal form - since it doesn't have a multivalued key. But the key is MemberID, and
the company name and location describe only a company, not a member. To achieve third
normal form, they must be moved into a separate table. Since they describe a company,
CompanyCode becomes the key of the new "Company" table.
The motivation for this is the same for second normal form: we want to avoid update and
delete anomalies. For example, suppose no members from the IBM were currently stored in the
database. With the previous design, there would be no record of its existence, even though 20
past members were from IBM!
BCNF A relation R is in Boyce-Codd normal form
(BCNF) if and only if every determinant is a candidate key
The definition of BCNF addresses certain (rather unlikely) situations which 3NF does not
handle. The characteristics of a relation which distinguish 3NF from BCNF are given below.
Since it is so unlikely that a relation would have these characteristics, in practical real-life
design it is usually the case that relations in 3NF are also in BCNF. Thus many authors make a
"fuzzy" distinction between 3NF and BCNF when it comes to giving advice on "how far" to
normalize a design. Since relations in 3NF but not in BCNF are slightly unusual, it is a bit
more difficult to come up with meaningful examples. To be precise, the definition of 3NF does
not deal with a relation that:
Example:
An example of a relation in 3NF but not in BCNF (and exhibiting the three properties listed)
was given above in the discussion of 3NF. The following relation is in BCNF (and also in
3NF):
We assume that each supplier has a unique supplier_name, so that supplier_no and
supplier_name are both candidate keys.
Functional Dependencies:
supplier_no → city
supplier_no → zip
supplier_no → supplier_name
supplier_name → city
supplier_name → zip
supplier_name → supplier_no
Comments:
The relation is in BCNF since both determinants (supplier_no and supplier_name) are unique
(i.e., are candidate keys).
The relation is also in 3NF since even though the non-primary-key column supplier_name
determines the non-key columns city and zip, supplier_name is a candidate key. Transitive
dependencies involving a second (or third, fourth, etc.) candidate key in addition to the primary
key do not violate 3NF.
Anomalies:
INSERT: We cannot record the city for a supplier_no without also knowing the supplier_name
DELETE: If we delete the row for a given supplier_name, we lose the information that the
supplier_no is associated with a given city.
Decomposition: