软件数据库的面向对象的视角外文文献翻译-数据库(编辑修改稿)

软件数据库的面向对象的视角外文文献翻译-数据库(编辑修改稿)内容摘要：

sign decisions affected by this refinement) to be part of the physical design process. Where we draw the line between design and tuning is not very important. OVERVIEW OF DATABASE TUNING After the initial phase of database design, actual use of the database provides a valuable source of detailed information that can be used to refine the initial design. Many of the original assumptions about the expected workload can be replaced by observed usage patterns。 in general, some of the initial workload specification will be validated, and some of it will turn out to be wrong. Initial guesses about the size of data can be replaced with actual statistics from the system catalogs (although this information will keep changing as the system evolves). Careful monitoring of queries can reveal unexpected problems。 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 内蒙古工业大学本科毕业设计外文文献翻译 6 consider the issues involved in conceptual schema (re)design from the point of view of 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。 rather, we want to create two distinct relations (possibly with different constraints and indexes on each). Incidentally, when we redesign the conceptual schema, especially if we are tuning an existing database schema, it is worth considering whether we should create views to mask these changes from users for whom the original schema is more natural. TUNING QUERIES AND VIEWS If we notice that a query is running much slower than we expected, we have to examine the query carefully to end the problem. Some rewriting of the query, perhaps in conjunction with some index tuning, can often ?x the problem. Similar tuning may be called for if queries on some view run slower than expected. When tuning a query, the first thing to verify is that the system is using the plan that 内蒙古工业大学本科毕业设计外文文献翻译 7 you expect it to use. It may be that the system is not finding the best plan for a variety of reasons. Some mon situations that are not handled efficiently by many optimizers follow: A selection condition involving null values. Selection conditions involving arithmetic or string expressions or conditions using the or connective. For example, if we have a condition = 2* in the WHERE clause, the optimizer may correctly utilize an available index on but fail to utilize an available index on . Replacing the condition by situation. Inability to recognize a sophisticated plan such as an indexonly scan for an aggregation query involving a GROUP BY clause. If the optimizer is not smart enough to and the best plan (using access methods and evaluation strategies supported by the DBMS), some system。