. Separating buyers and sellers In any auction model, (Com web hosting)
Saturday, October 27th, 2007. Separating buyers and sellers In any auction model, a buyer can actually also be a seller (bidding on their own items should be prohibited). It might seem sensible to merge the buyer and seller tables, and also merge the two history tables together. Traditionally, in many database models, any types of customer and supplier details are generally separated. This is usually because they are not one and the same, from the perspective of content, as opposed to a structural point of view. In an auctioning database model, separating buyers from sellers is likely to be the most sensible option, simply because it is probably the norm (not always the case) that the buyers are unlikely to be sellers, and visa versa. Obviously, with normalization applied during the design phase (discussed in Chapter 10), it may make sense to separate buyers, sellers, and buyer-sellers (auctioneers who both buy and sell), all into three separate tables. . Referential integrity keys All the most basic relationships have been established between the different tables. Identifying appropriate primary and foreign keys is more a design issue than an analysis issue. Keys will be established in Chapter 10, which covers design. . Category hierarchy In some situations, separating static tables (such as the three category tables) may not be the most efficient option. There may be a case for merging all categories into a single table. The single table would contain all three category levels using specialized parent and child fields, for each category record. Because this is once again a design issue and not an analysis issue, it is covered in Chapter 10. Try It Out Analyzing an OLTP Database Model Create a simple analytical-level OLTP database model for a Web site. This Web site allows creation of free classified ads for musicians and bands. Here s a simplistic approach: 1. Identify the operations of the company. 2. Draw up a picture of basic tables. 3. Establish simple relationships. 4. Create basic fields within each table. How It Works Figure 9-17 shows some basic information categories, both static and transactional in nature. Instruments and skills statically describe relatively static musicians (musicians come and go, skills and instrument classifications do not). This probably makes musicians dynamic transactional information. Aband has a specific genre such as playing rock music, punk, classic rock, and so on. Thus, the band is dynamic and the genre is static. The classified advertisement itself is most certainly dynamic in nature. Just in case you are wondering where all this stuff is going (the three points just mentioned), these factors are all design issues, not analysis issues. This chapter deals with the analytical process of discovering basic contents of the auctioning database model. Chapter 10 deals with design issues. The objective of these case study directed chapters is to introduce a data model in a manner that covers each concept step-by-step, making details easy to understand and absorb. 241 Planning and Preparation Through Analysis
In case you need quality webspace to host and run your web applications, try our personal web hosting services.