【正文】 n proportion to I/O and CPU costs. Users’ locations are constantly changing, and mobile puters have a limited battery life. Therefore, the true munication costs is connection time and battery usage in addition to bytes transferred, and change constantly depending on location. Data is frequently replicated to minimize the cost of accessing it from different locations. 8 As a user moves around, data could be accessed from multiple database servers within a single transaction. The likelihood of losing connections is also much greater than in a traditional work. Centralized transaction management may therefore be impractical, especially if some data is resident at the mobile puters. We may in fact have to give up on ACID transactions and develop alternative notions of consistency for user programs. MAIN MEMORY DATABASES The price of main memory is now low enough that we can buy enough main memory to hold the entire database for many applications。 for example, the optimizer may not be using some indexes as intended to produce good plans. Continued database tuning is important to get the best possible performance. TUNING THE CONCEPTUAL SCHEMA In the course of database design, we may realize that our current choice of relation schemas does not enable us meet our performance objectives for the given workload with any (feasible) set of physical design choices. If so, we may have to redesign our conceptual schema (and reexamine physical design decisions that are affected by the changes that we make). We may realize that a redesign is necessary during the initial design process or later, after the system has been in use for a while. Once a database has been designed and populated with data, changing the conceptual schema requires a significant effort in terms of mapping the contents of relations that are affected. Noheless, it may sometimes be necessary to revise the conceptual schema in light of experience with the system. We now consider the issues involved in conceptual schema (re)design from the point of view of 6 performance. Several options must be considered while tuning the conceptual schema: We may decide to settle for a 3NF design instead of a BCNF design. If there are two ways to depose a given schema into 3NF or BCNF, our choice should be guided by the workload. Sometimes we might decide to further depose a relation that is already in BCNF. In other situations we might denormalize. That is, we might choose to replace a collection of relations obtained by a deposition from a larger relation with the original (larger) relation, even though it suffers from some redundancy problems. Alternatively, we might choose to add some fields to certain relations to speed up some important queries, even if this leads to a redundant storage of some information (and consequently, a schema that is in neither 3NF nor BCNF). This discussion of normalization has concentrated on the technique of deposition, which amounts to vertical partitioning of a relation. Another technique to consider is horizontal partitioning of a relation, which would lead to our having two relations with identical schemas. Note that we are not talking about physically partitioning the cuples of a single relation。 the workload consists of a mix of queries and updates. Users also have certain requirements about how fast certain queries or updates must run or how many transactions must be processed per second. The workload description and users’ performance requirements are the basis on which a number of decisions have to be made during physical database design. To create a good physical database design and to tune the system for performance in response to evolving user requirements, the designer needs to understand the workings of a DBMS, especially the indexing and query processing techniques supported by the DBMS. If the database is expected to be accessed concurrently by many users, or is a distributed database, the task bees more plicated, and other features of a DBMS e into play. DATABASE WORKLOADS The key to good physical design is arriving at an accurate description of the expected workload. A workload description includes the following elements: 1. A list of queries and their frequencies, as a fraction of all queries and updates. 2. A list of updates and their frequencies. 3. Performance goals for each type of query and update. 4 For each query in the workload, we must identify: Which relations are accessed. Which attributes are retained (in the SELECT clause). Which attributes have selection or join conditions expressed on them (in the WHERE clause) and how selective th