The problem as shown (Christian web host) in Figure 10-33 is
The problem as shown in Figure 10-33 is that there is essentially an operational requirement for a one-tomany (master-detail) relationship between listing and bid facts. Why? Think about how this data would be used. If you wanted to track listing information alone, then there is no problem. If you wanted to analyze the pattern of bids against particular types of listings, then that LISTING to BID relationship would be required. Establishing a relationship between multiple fact tables causes serious problems. The reason why goes back to the existence of the fact-dimensional data warehouse database model itself. Data warehouse database models were devised to split very small tables, linked in a single-layer hierarchy of dimensions (a star schema), all linked to a single fact table. Fact tables are very large. The most efficient types of query joins are those between one or more small tables (the dimensions) and only a single large table. That great big humungous table is the fact table. And there should also be only one fact table in a star schema. Never relate or join fact tables. You might wait a week for queries to execute! Linking more than one fact table together results in a join between two very large tables, which can be frighteningly inefficient defeating the very existence of the fact-dimensional data warehouse database model. Don t do it! A solution is to merge and denormalize the fact tables as shown in Figure 10-34. The HISTORY fact table is not a problem because histories apply to sellers and buyers. In the real world, histories are used by sellers and buyers to assess whether they are dealing with an honest trader or a complete shyster! Figure 10-34: Reducing the three fact tables in Figure 10-33 to two fact tables, based on operational requirements. Listing-Bid Facts Seller seller_id seller popularity_rating join_date address return_policy international payment_methods Location location_id region country state city Time time_id month quarter year Category_Hierarchy category_id parent_id (FK) category Listing_Bids_History fact_id time_id (FK) buyer_id (FK) location_id (FK) seller_id (FK) category_id (FK) listing# listing_description listing_image listing_start_date listing_days listing_currency listing_starting_price listing_reserve_price listing_buy_now_price listing_number_of_bids listing_winning_price listing_winner_buyer bidder bidder_price bidder_date Buyer buyer_id buyer popularity_rating join_date address Seller seller_id seller popularity_rating join_date address return_policy international payment_methods Location location_id region country state city Time time_id month quarter year Category_Hierarchy category_id parent_id (FK) category History fact_id time_id (FK) buyer_id (FK) location_id (FK) seller_id (FK) category_id (FK) history_buyer history_buyer_comment_date history_buyer_comments history_seller history_seller_comment_date history_seller_comments Buyer buyer_id buyer popularity_rating join_date address History Facts Combining the listing and bid facts eliminates the inappropriate relationship 310 Chapter 10
You want to have a cheap webhost for your apache application, then check apache web hosting services.