Oracle XSQL- P21 pptx

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 customer 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. 380 Chapter 14 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. Building XSQL Web Applications 381 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 navigation 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 navigational 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 category 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 ResultsCategory Page 382 Chapter 14 Figure 14.3 Product page. Figure 14.4 Search results page. Building XSQL Web Applications 383 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 products 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 diagram 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. 384 Chapter 14 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 requirements 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 formulated 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 promotions. Our interface design puts usability limits on the number of each of these, but Building XSQL Web Applications 385 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 category identifier. The product category identifier will be embedded in the link. This illustrates an important point of this exercise. You need to look not only at what is displayed 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 386 Chapter 14 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 functionality 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 subordinate 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 product categories and the products. A single product can belong to multiple product categories, 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 discussion, you know that denormalization is best reserved for data warehousing-type applications. If this were an extremely large product catalog, then a denormalized database Building XSQL Web Applications 387 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 denormalized database based on a normalized 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 388 Chapter 14 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 primary 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 multiple 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) product to primary product category, and (3) multiple product categories to product. 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. Promotion Product Building XSQL Web Applications 389 [...]... xmlns:xsql=”urn :oracle- xsql”> SELECT id,name,description FROM product_category Building XSQL Web Applications The next page is the product list page Using the SQL developed earlier, it appears as follows: ... id,name,description FROM product_category ORDER BY name SELECT url,product_id FROM promotion WHERE status=’ACTIVE’ ORDER BY slot The next SQL statement to write is for the text search capability You’ll use the Oracle text that you learned about in Chapter 8 for this Our pseudo-SQL was: SELECT the product id, the product name, the product summary, FOR all of the products that meet the search criteria IN ORDER... the xsql:include-xsql action The first step is to create the product category navigational page A first cut of it looks like this: SELECT id,name FROM product_category This looks just like all of the other XSQL that you’ve seen as you’ve learned the basics of XSQL But now, you are developing not just a... relating to completely different data Using the rowset-element and the row-element parameters, you can better organize your data: SELECT * FROM product_category The next page to complete is the promotion page It is only used once in our site, but... it has the aspect of its own element Using the same technique as before, you can create it so that it can fit anywhere in the site SELECT url,product_id FROM promotion WHERE status=’ACTIVE’ ORDER BY slot Now you can start with the development of the home page... table With the fourth entity in place, our complete ERD appears in Figure 14.10 The field names have been changed to valid database names, and the primary keys have been noted If you have a tool such as Oracle Designer, you can plug in the ERD and it will generate a script for you that will create all of the tables In the next section, we’ll translate the ERD by hand to come up with our database Product... using bind parameters It also sets a default parameter for category_id in case the page is called without the category_id parameter SELECT p.id AS product_id, p.name AS product_name, . changed to valid database names, and the primary keys have been noted. If you have a tool such as Oracle Designer, you can plug in the ERD and it will generate a script for you that will create. status=’ACTIVE’ ORDER BY slot The next SQL statement to write is for the text search capability. You’ll use the Oracle text that you learned about in Chapter 8 for this. Our pseudo-SQL was: SELECT the product. looks like this: <?xml version=”1.0”?> <xsql:query connection=”momnpup” xmlns:xsql=”urn :oracle- xsql”> SELECT id,name FROM product_category </xsql:query> This looks just like all