Oracle XSQL- P21 pptx

Product Page Home Page Search Results Category Page... Here’s a pseudo-SQL statement for the product categories: SELECT the product category name, the product category description, the p

A Sample Application

Our sample application is an online catalog for the Mom N’ Pup retailer In the course

of developing this application, we’ll run into some issues that are best resolved with action handlers and a programmatic approach For now, we’ll follow roughly the design process that we laid out in the previous section Much of the remainder of our discussion in this chapter will revolve around our development In this section, we’ll develop the site map for the application and implement the database schema

The Requirements

The first step in our process is to state the requirements for the application The cus-tomer wants an online catalog that will be available over the Web They currently don’t have a database, so they’ll need to have one built to contain the data They want the users to either browse based on product category or perform searches based on the descriptions In addition, they want to be able to edit the prices of products through a Web interface At a high level, the requirements are as follows:

■■ Web-based online catalog, browsable by product category and searchable by keywords

■■ Database to store data

■■ Edit function for prices

In addition to these requirements, they are also throwing a couple of curve balls First, they want some products to belong to more than one product category For instance, hand soap could be used in the kitchen or in the bathroom They want hand soap products to appear under both kitchen supplies and bathroom supplies, though for internal purposes it should be stored under only under one product category They’ve browsed some other product sites and don’t like it when too many product titles are loaded at the same time Instead, they want the results of a query to be sepa-rated across several pages

Mom N’ Pup also runs specials from time to time They want the home page to have

a list of specials on the right-hand side of the home page Clicking on the ad will take the shopper directly to the product page for the particular product The specials should also be configurable through a Web-based interface

The customer is also aware that the Web is an evolving medium, and they want to

be sure that their catalog will be usable via different types of interfaces They require that a demo version of the catalog is available through Wireless Application Protocol (WAP) that allows browsing of products only They figure if the application design allows for this, then they’ll be ready for any type of interface This leaves us with our secondary requirements:

■■ Products can appear as members of multiple product categories

■■ Product listings should paginate

■■ Ads for specials should be listed

■■ Specials should be configurable through a Web interface

Now at this point, the imaginary customer would sign an imaginary contract drawn

up by imaginary lawyers Luckily for us, this step isn’t necessary If this were a real project, we’d also need to examine issues such as where the site is going to be hosted, how the data is going to be loaded, and how the database is going to be backed up and,

in case of a failure, restored These issues are largely beyond the scope of this book, so we’ll punt those Instead, we’ll begin with the development work starting with the user interface design

Application Interface Design

In keeping with the process developed earlier, the first step is to lay out the design of the interfaces You may have noticed that this doesn’t have to be the next step If we wanted, we could work from the other direction and start dealing with the database first However, starting with the interface is better All applications, even Web services applications, have users If the user experience isn’t good, the application will ulti-mately fail By starting on the interface, you increase the chances of success The code and the database are molded around the interface instead of the other way around

The logical place to start is the home page of the application From the requirements,

we know that users should be able to browse by product category and perform text searches The customer also wants a set of ads to appear on the right-hand side of the browser window A quick mockup looks like Figure 14.1

Figure 14.1 HTML mockup of the home page.

With this as a starting point, the rest of the site can be formulated The primary goal

of the site is to drive people to product-specific pages Each product needs to have its own page with descriptions and pricing information It can be reached through one or more product category pages, a search result page, or the ad The primary site naviga-tion is diagrammed in Figure 14.2

If you stopped here, you would have a functional application, but not that pleasing

of a user experience Once users start to drill down, they wouldn’t have any way to navigate back to the home page or across the site Users need some sort of navigational elements to help them move around the site The proposed resolution is to have a nav-igational tool bar across the top and a listing of product categories along the left-hand side These navigational elements will appear in all of the subordinate pages—the product pages, the search result pages, and the product category pages A mockup of a product page is diagrammed in Figure 14.3

We have two mockups left to complete—the search results page and the product cat-egory page Both are very similar in nature—they list products The search results page

is simpler in nature and is displayed in Figure 14.4 It lists the products based on their names, and the links lead to the respective product pages

Figure 14.2 Primary site navigation.

Product Page

Home Page

Search Results Category Page

Figure 14.3 Product page.

Figure 14.4 Search results page.

Our last page to design is the product category page The main difference is that all

of these products are related by product category, and the product category name and description should appear at the top of the page It is pictured in Figure 14.5

In these last two examples, you’ll notice that there are Previous and Next buttons at the bottom of the pages These meet requirements for pagination of the results In the mockup, Previous is grayed out because we are presumably at the beginning of the search results If we are at the end, the Next link should be grayed out If a particular search doesn’t return enough results to require pagination, neither should appear This takes care of the public catalog Now, attention is needed for the price editor and the promotion editor The customer wants to be able to change the prices of the items easily and to change multiple items at the same time The editor page itself can appear similar to Figure 14.6 The top search field allows users to search for the prod-ucts that they wish to edit

At this point in the process, we would ask our customer to review our mockups in order to ensure that we are heading in the right direction This is another advantage of starting with the interface—your customer can see it and understand it An E-R dia-gram isn’t nearly as exciting to most customers as a couple of Web pages tied together that kind of look like they work This is also the time when the requirements can be clarified and possibly expanded (Just make sure that if the project expands, the price also expands.)

In our case, Mom N’ Pup is delighted with our work and are already hailing us as geniuses! (Hey, we might as well make the most out of our imaginary customers They are much more malleable than the real ones.)

Figure 14.5 Product category page.

Figure 14.6 Price editor page.

Database Requirements

At this point, you’ve moved through steps 1 and 2 in our process You have the require-ments and you’ve developed an interface The next step is to formulate the database requirements To do this, you need to examine the interface design and identify the areas of your interface that interact with your database With the areas identified, you can come up with pseudo-SQL statements that you will need for the required functionality

First, a word is needed about our pseudo-SQL This isn’t yet another new-fangled language you have to learn It’s just a way to describe the data that is needed from the database in plain English Because we don’t have a database yet, we don’t have to be syntactically correct Even if we did have a database, this method is a good way to quickly determine the requirements without getting mired in the workings of the actual database For our pseudo-SQL, we deliberately leave the tables out of the pic-ture for now and focus on the pieces of data that are needed Determining which fields should live in which tables is a task that will be addressed in the database design phase

To find these database-related areas, we need only to examine the mockups formu-lated in the previous section Let’s start with the home page described in Figure 14.1 There are two dynamic data areas: (1) the listing of product categories and (2) the pro-motions Our interface design puts usability limits on the number of each of these, but

they can’t be static They should be generated from the database Here’s a pseudo-SQL statement for the product categories:

SELECT the product category name,

the product category description, the product category identifier FOR all of the product categories

IN alphabetic ORDER OF the product category name

Our statement retrieves the data that is seen on the screen as well as the product cat-egory identifier The product catcat-egory identifier will be embedded in the link This illustrates an important point of this exercise You need to look not only at what is dis-played in the mockups, but also at data points that are needed for behind-the-scenes work The next pseudo-SQL statement also illustrates this point:

SELECT the URL for the promotion image,

the product id that the promotion should link to, the slot for the promotion

FOR each of the promotions that should be displayed

There is one database-related area left on the home page: the search field It is actu-ally a simple static form, but it will need to be linked to an XSQL page that can handle the form For talking purposes, let’s name the form handler textSearch.xsql The textSearch.xsql page will need to have its own SQL statement based on the following:

SELECT the product id,

the product name, the product summary, FOR all of the products that meet the search criteria

IN ORDER OF the most relevant searches first

When the Search button is pressed, the search results page will be displayed The dynamic data area for that page is furnished with the preceding SQL statement When users click on a product, they need to be taken to the product page The product ID can

be embedded in the link to handle this The link will be to product_details.xsql, and this XSQL page should contain a query like this:

SELECT the product name,

the product summary, the product price, the complete product description, FOR one particular product

This covers our search functionality, and this same query can be used when users click on a promotion and when they select a product from the product category page Now, let’s back up and cover the browsing functionality Our product category names will be linked to the product category pages As with the search results, we can assume

that the type_id for a product category will be embedded in the links that will be generated for the home page They’ll be handled by an XSQL page that you will call product_type.xsql It needs a SQL statement to select the products It should look something like this:

SELECT the product id,

the product name,

the product summary,

FOR all of the products in a particular category

IN alphabetic ORDER OF the product name

The queries that have been developed thus far cover nearly all of the primary func-tionality of the application Now we have to flesh out the navigational aspects The first step is the listing of product categories that appear on the left side of the subordi-nate pages This one is similar to our earlier query for the home page, except we need less information:

SELECT product category name,

product category id

FOR all of the product categories

IN alphabetic ORDER OF the product category name

We also have a horizontal navigational element across the top of the page It con-tains a text search field along with a link to the home page and the product category The home page link is always the same The category link is a bit trickier We could write a query that pulls the primary category for the displayed product Remember, though, that one of our requirements is to be able to assign multiple categories to a product The product category that is returned by the query may not be the category that the user used to navigate to this page Thus, we shouldn’t formulate a query for this information Rather, we need to pass the category ID as a parameter

Our analysis for the public part of the application is now complete The price editor part of the application is covered separately later in the chapter

Database Design

In the previous section, we identified all of the areas in our application that should interact with the database We have a good idea of the kind of database that is needed Now the trick is to put the database together Before plunging in, the requirements should be revisited The customer will be providing XML for the product descriptions, and we’ve determined that it makes the most sense to store the XML documents in the database We also know that there is a many-to-many relationship between the prod-uct categories and the prodprod-ucts A single prodprod-uct can belong to multiple prodprod-uct cate-gories, and of course, a single product category can have multiple products

With these requirements in mind, we can consider the key question in database design: Should the database be normalized or denormalized? Per our earlier discus-sion, you know that denormalization is best reserved for data warehousing-type appli-cations If this were an extremely large product catalog, then a denormalized database

may be necessary However, once you go the route of optimizing for performance, you risk making a database that is hard to extend for other applications that might come along Because our product catalog isn’t going to contain hundreds of thousands of items, the normalization approach is best Besides, it’s far easier to make a denormal-ized database based on a normaldenormal-ized one than to try to go the other way

Now it’s time to look back at the pseudo-SQL developed earlier and determine the necessary fields Each field should be grouped with an entity

PRODUCT

Product identifier

Product price

Product name

Product summary

Primary product category

Complete product description

PRODUCT CATEGORY

Product category identifier

Product category name

Product category description

PROMOTION

Promotion slot

Product ID for the promotion

URL of the promotional image

Promotion status

The next step is to make sure that our entities are in the third normal form, described earlier in this chapter You can determine this by stepping through first, second, and third normal forms The first normal form says that there shouldn’t be multiple columns for the same field This doesn’t look to be a problem for any of our entities If the product category had columns for each product in the category, we would be in violation of the first normal form Usually, developers are instinctively in compliance with first normal form However, if you find yourself putting a comma-delimited list

in a column, then you are in violation of the first normal form You should take what-ever data that you are listing and make a table for it

Next, we need to see if we are in compliance with the second normal form The rule for the second normal form states that you need to have a primary key, and the nonkey

fields need to be dependent on it The product and the product category entities meet this test—you can use the product identifier and product category identifier as the pri-mary keys However, the promotion entity isn’t as straightforward You could use either promotion slot or product id as a primary key, but this is a bit limiting What if you want to tie multiple promotions to a single product? What if you want to tie mul-tiple promotions to a particular slot and rotate them? It is best to modify the promotion entity so that it has a promotion ID that is independent of the other entities:

PROMOTION

Promotion ID

Promotion slot

Product ID for the promotion

URL of the promotional image

Promotion status

Last, you need to check to make sure that all of the entities are in third normal form The question is: Are there any nonkey columns dependent on other nonkey columns? There are not If we had combined the product and the product category tables, then there would be a problem The product category name and description would be dependent on each other The purpose of third normal form is to make sure that tables shouldn’t be split up

Now that the database is normalized, it’s time to set up the relationships between the different entities There are three relationships: (1) promotion to product, (2) prod-uct to primary prodprod-uct category, and (3) multiple prodprod-uct categories to prodprod-uct The promotion-to-product relationship is easiest Per the requirements, it is a one-to-one relationship, but there is no harm in making it a many-to-one relationship This yields the ERD for these two entities, as shown in Figure 14.7

In terms of our fields, the product ID for the promotion field in the promotion entity can be tied to the product identifier field in the product entity When you implement the database, you can create a foreign key constraint between these two columns

The primary product category to product relationship looks basically the same Every product needs to have a product category to which it belongs The diagram for this relationship is shown in Figure 14.8

Figure 14.7 ERD for promotion and product.