数据库设计外文翻译

外文翻译：

索引

原文来源：Thomas Kyte．Expert Oracle Database Architecture ．2nd Edition．

译文正文：

什么情况下使用B*树索引?

我并不盲目地相信“法则”（任何法则都有例外），对于什么时候该用B*索引，我没有经验可以告诉你。为了证明为什么这个方面我无法提供任何经验，下面给出两种等效作法：?使用B*树索引，如果你想通过索引的方式去获得表中所占比例很小的那些行。

?使用B *树索引，如果你要处理的表和索引许多可以代替表中使用的行。

这些规则似乎提供相互矛盾的意见，但在现实中，他们不是这样的，他们只是涉及两个极为不同的情况。有两种方式使用上述意见给予索引：

?作为获取表中某些行的手段。你将读取索引去获得表中的某一行。在这里你想获得表中所占比例很小的行。

?作为获取查询结果的手段。这个索引包含足够信息来回复整个查询，我们将不用去查询全表。这个索引将作为该表的一个瘦版本。

还有其他方式—例如，我们使用索引去检索表的所有行，包括那些没有建索引的列。这似乎违背了刚提出的两个规则。这种方式获得将是一个真正的交互式应用程序。该应用中，其中你将获取其中的某些行，并展示它们，等等。你想获取的是针对初始响应时间的查询优化，而不是针对整个查询吞吐量的。

在第一种情况（也就是你想通过索引获得表中一小部分的行）预示着如果你有一个表T （使用与早些时候使用过的相一致的表T）,然后你获得一个像这样查询的执行计划：

ops$tkyte%ORA11GR2> set autotrace traceonly explain

ops$tkyte%ORA11GR2> select owner, status

2 from t

3 where owner = USER;

Execution Plan

----------------------------------------------------------

Plan hash value: 1049179052

------------------------------------------------------------------

------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 2120 | 23320 |

| 1 | TABLE ACCESS BY INDEX ROWID |T | 2120 | 23320 |

| *2 | INDEX RANGE SCAN | DESC_T_IDX | 8 | |

------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access(SYS_OP_DESCEND("OWNER")=SYS_OP_DESCEND(USER@!))

filter(SYS_OP_UNDESCEND(SYS_OP_DESCEND("OWNER"))=USER@!)

你应该访问到该表的一小部分。这个问题在这里看是INDEX (RANGE SCAN) 紧跟在

TABLE ACCESS BY INDEX ROWID之后。这也意味着Oracle先读取索引，然后获取索引项。该索引项将执行一个数据库块读（逻辑或者物理的I/O）去获取行数据。如果你想通过索引去访问数据表T中的大部分数据，这不是最高效的方式（我们将很快定义什么是大部分的数据）。

第二种情况，（也就是你想通过索引去代替表），你将通过索引去处理100%（事实上可以是任何比例）的行。也许你想通过索引索引去获得一个缩小版的表。接下来的查询证明了这种方式：

ops$tkyte%ORA11GR2> select count(*)

2 from t

3 where owner = user;

Execution Plan

----------------------------------------------------------

Plan hash value: 293504097

---------------------------------------------------------------------------

---------------------------------------------------------------------------

| 0 | SELECT STA TEMENT | | 1 | 6 | 17 (0) | 00:00:01 |

| 1 | SORT AGGREGAT E | | 1 | 6 | .. | .|

| * 2 | INDEX RANGE SCAN | T_IDX | 2 120 | 12720 | 17 (0) | 00: 00: 01 |

---------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("OWNER"=USER@!)

这里，仅仅是使用索引去作为查询的返回集-现在再也不在乎我们只通过索引的方式，想访问多少比例的行。从执行计划中可以看到，查询语句从未访问过表，仅仅扫描索引结构本身。

理解两种概念的区别很重要。当执行TABLE ACCESS BY ROWID操作时，我们必须确保仅访问表中一小部分的块，也就相当于仅访问一小部分的行或者是尽量块地获取第一的数据。（最终的用户将会为了这几行数据等得不耐烦的）。如果想通过访问比较高比例的行（所占比例高于20%），使用B*索引的话，它将花费比全表扫描更多的时间。

使用第二种查询方式，那些在索引中可以找到所需结果的，情况就完全不同了。我们读取索引块，然后拾取其中的很多行进行处理，如此继续下一个索引块，从不访问表。某些情况下，还可以在索引上执行一个快速全面扫描。快速全面扫描是指，数据库不按特定的顺序读取索引块，只是开始读取它们。这里不再是将索引只当一个索引，此时更像是一个表。如果采用全表扫描，将不会按索引项来顺序获取行。

一般来讲，B*树索引将会被放在查询时频繁使用的列上。而且我们希望从表中只返回少量的数据或者最终用户的请求想立即得到反馈。在一个瘦表（也就是一个含有很少的列或者列很小）中，这个比例可能很小。一个查询,使用该索引应该可以在表中取回约2% ~ 3%或更少的行。在一个胖表（也就是含有很多列或者列很宽）中，这个比例将一直上升到该表的20%~25%。以上建议并不对每个人都有作用。这个比例并不直观，但很精确。索引根据索引键进行排序存储。索引会按键的有序顺序进行访问。索引指向的块都随机存储在堆中。因此，我们通过索引访问表时，会执行大类分散、随机的I/O。这里的“分散”是指，索引会告诉我们读取块1，然后是块1000,块205，块1，块1032，块1等等。它们不会要求我们按照块1，块2然后块3的方式。我们将以一种非常随意的方式读取和重新读取块，这种块I/O可能非常慢。

让我们看一下简化版的例子，假设我们通过索引读取一个瘦表，而且要读取表中的20%的行。若这个表中有100000行，这个表得20%就是20000行。如果行大小约为80个字节，在一个块大小为8KB的数据库中，我们将在每个块中获得100行数据。这也就意味着这个表有1000个块。了解这些，计算起来就很容易了。我们想通过索引去读取2000行，这也就意味着几乎相当于20000次的TABLE ACCESS BY ROWID 操作。这将导致执行这个操作要处理20000个表块。不过，这个表总共才只有1000块。我们将对表的每个块要执行读和处理20次。即时把行的大小提高到一个数量级，达到每行800字节，这样每块有10行，那样这个表现在有10000块。要通过索引20000行，仍要求我们把每一块平均读取2次。在这种情况下，全表扫描就比使用索引高效得多。因为每个块只会命中一次。如果把查询使用这个索引来访问数据，效率都不会高，除非对应800字节的行，平均只访问表中不到5%的数据（这样一来，我们访问的大概为5000块），如果是80字节的行，则访问的数据应当只占更小的百分比（大约0.5%或更少）。

什么情况下使用位图索引?

位图索引是最适合于低相异基数数据的情形（也就是说，与整个数据集得基数相比，这个数据只有很少几个不同的值）。对此作出量化是不太可能的——换句话说，就是很难定义这个低相异基数数据有到底多么不同。在一个有几千条记录的数据集中，2就是一个低相异基数，但是在一个只有两行记录的数据表中，2就不再是低相异基数了。而在一个上千万或者上亿条记录的表中，甚至100,000都能作为一个低相异基数。所以，多大才算是低相异基数，这要相对于结果集得大小来说。这里是指行集中不同项的个数除以行数应该是一个很小的数（接近于0）。例如，GENDER列可能取值为M、F和NULL。如果一个表中有20,000条员工记录，那么你将会发现3/20,000=0.00015。同样地，10,000,000中100,000个不同值得比例为0.01,——同样，值很小。这些列就可以建立位图索引。他们可能不合适建立B*树索引，因为每个值可能会获取表中的大量数据。如同前面所述，B*数索引一般来讲是选择性的。位图索引不带有选择性的——相反，一般是“没有选择性”的。

位图索引在有很多即时查询的时候极其有用，尤其是在查询涉及很多列或者会生成诸如COUNT之类的聚会。例如，假设有一个含有GENDER，LOCATION，和AGE_GROUP三个字段的大表。在这个表中，GENDER的值为M或者F，LOCATION可以选取1到50之间的值，AGE_GROUP为代表18岁及以下，19-25，26-30，31-40，和40岁及以上的代码。现在不得不通过以下的方式执行大量的即时查询：

Select count(*)

from T

where gender = 'M'

and location in ( 1, 10, 30 )

and age_group = '41 and over';

select *

from t

where ( ( gender = 'M' and location = 20 )

or ( gender = 'F' and location = 22 ))

and age_group = '18 and under';

select count(*) from t where location in (11,20,30);

select count(*) from t where age_group = '41 and over' and gender = 'F';

你会发现，这里用传统的B*树索引是没用的。如果想通过索引获取结果集，你将件至少组合3~6个B*树的索引获取数据。从任意的3列或任何3列的子集将会出现。你将需要会在以下列建立大量串联B*数索引：

?GENDER, LOCATION, AGE_GROUP：对应使用三列的查询，或者使用GENDER和LOCATION的查询或者单独使用GENDER的查询

?LOCATION,AGE_GROUP：对应使用LOCATION和AGE_GROUP或只用LOCATION的查询。

?AGE_GROUP,GENDER：对应只用了AGE_GROUP和GENDER或者只用AGE_GROUP的查询。

为检索被检索到数据量，还可以有其他排列，以减少所扫描索引结构的大小。这是因为在此忽略了这样一个重要事实：对这种低基数数据建B*树索引是不明智的。

这里位图索引就派上用场了。利用分别建立在各个列上的3个较小的位图索引，就能高效地满足前面的所有条件。Oracle只需使用函数AND，OR和NOT，利用位图将这三个索引放在一起，就能得到引用该三列的结果集。它会得到合并后的位图，如果必要还可以将位图中的“1”转换为rowid来访问数据（如果只是统计与条件匹配的行数，Oracle就只会统计“1”位的个数）。下面来看一个例子。首先，生成一些测试数据（满足我们指定的相异基数），建立索引，我们将得到DBMS_RANDOM包来生成我们的分布要求的随机数据：

ops$tkyte%ORA11GR2> create table t

2 ( gender not null,

3 location not null,

4 age_group not null,

5 data

6 )

7 as

8 select decode( ceil(dbms_random.value(1,2)),

9 1, 'M',

10 2, 'F' ) gender,

11 ceil(dbms_random.value(1,50)) location,

12 decode( ceil(dbms_random.value(1,5)),

13 1,'18 and under',

14 2,'19-25',

15 3,'26-30',

16 4,'31-40',

17 5,'41 and over'),

18 rpad( '*', 20, '*')

19 from big_table.big_table

20 where rownum <= 100000;

Table created.

ops$tkyte%ORA11GR2> create bitmap index gender_idx on t(gender);

Index created.

ops$tkyte%ORA11GR2> create bitmap index location_idx on t(location);

Index created.

ops$tkyte%ORA11GR2> create bitmap index age_group_idx on t(age_group);

Index created.

ops$tkyte%ORA11GR2> exec dbms_stats.gather_table_stats( user, 'T');

PL/SQL procedure successfully completed.

现在我们来看看前面各个即时查询的相应查询计划:

ops$tkyte%ORA11GR2> Select count(*)

2 from T

3 where gender = 'M'

4 and location in ( 1, 10, 30 )

5 and age_group = '41 and over';

Execution Plan

----------------------------------------------------------

Plan hash value: 1811480857

------------------------------------------------------------------------------------

------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 13 | 5 (0)|

| 1 | SORT AGGREGATE | | 1 | 13 | |

| 2 | BITMAP CONVERSION COUNT | | 1 | 13 | 5 (0)|

| 3 | BITMAP AND | | | | |

| 5 | BITMAP OR | | | | |

------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("GENDER"='M')

6 - access("LOCATION"=1)

7 - access("LOCATION"=10)

8 - access("LOCATION"=30)

9 - access("AGE_GROUP"='41 and over')

这个例子显示了位图索引的强大能力。Oracle可以看到在（1，10，30）中的位置和知道读取赋予3个值的位置的索引，且在位图中对这些“位”进行逻辑OR运算。然后将所得到的位图与AGE_GROUP=’41 AND OVER’和GENDER=’M’的相应位图执行逻辑AND运算。再统计“1”的个数，这样就得到了答案：

ops$tkyte%ORA11GR2> select *

2 from t

3 where ( ( gender = 'M' and location = 20 )

4 or ( gender = 'F' and location = 22 ))

5 and age_group = '18 and under';

Execution Plan

----------------------------------------------------------

Plan hash value: 906765108

---------------------------------------------------------------------------------

---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 510 | 16830 |78 (0)|

| 1 | TABLE ACCESS BY INDEX ROWID | T | 510 | 16830 |78 (0)|

| 2 | BITMAP CONVERSION TO ROWIDS | | | | |

| 3 | BITMAP AND | | | | |

| 5 | BITMAP OR | | | | |

| 6 | BITMAP AND | | | | |

| 9 | BITMAP AND | | | | |

---------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("AGE_GROUP"='18 and under')

7 - access("LOCATION"=22)

8 - access("GENDER"='F')

10 - access("GENDER"='M')

11 - access("LOCA TION"=20)

这个逻辑与前面是类似的。由计划显示：这里执行逻辑OR的两个条件是通过AND适当的位图逻辑计算得到的，然后再对这些结果进行OR运算。再加上一个AND去满足AGE_GROUP='18 AND UNDER'，那样就获得了满足条件的结果。由于这一次要请求具体的行，索引Oracle将转换每一个位图1和0为rowid，来获取源数据。

在数据仓库或者一个支持很多即时SQL查询的大型报告系统中，能同时合理地使用尽可能多的索引确实很有作用。在这里将几乎不使用传统的B*树索引，或者是根本上无用。当被即时查询的列数增加时，B*树索引的组合数也就同时增加了。

然而，有些时候使用位图索引也是不合适的。它们在读密集型环境中是运行很好的，但是在写密集型环境中运行效果极度差。原因是一个位图索引键条目对应多行。如果一个会话修改所索引到的数据，那么所有被索引到的行将受影响，被锁定。Oracle无法锁一个索引项中的某一位，它锁住整个索引项。倘若其他修改也需要更新同样的这个位图索引项，它将被锁在外面。由于每次更新都会无意识地锁住很多行，阻止它们的位图列被及时地更新，这样将大大影响并发性。在此不是像你所想的那样锁定每一行——只是锁定部分。位图是以大块地进行存储，所以使用前面的EMP就可以看到，索引键ANAL YST在索引中出现了多次，每次都是指向数百行。更新一行时如果修改了JOB列，则需要独占地访问其中两个索引项：对应老值的索引项和对应于新值得索引项。这两个条目指向的数百行就不允许其他会话修改直到UPDATE提交。

原文正文：

When Should Y ou Use a B*Tree Index?

Not being a big believer in “rules of thumb”(there are exceptions to every rule), I don’t have any rules of thumb for when to use (or not to use) a B*Tree index. To demonstrate why I don’t have any rules of thumb for this case, I’ll present two equally valid ones:

? Only use B*Tree to index columns if you are going to access a very small percentage of the rows in the table via the index.

? Use a B*Tree index if you are going to process many rows of a table and the index can be used instead of the table.

These rules seem to offer conflicting advice, but in reality, they do not—they just cover two extremely different cases. There are two ways to use an index given the preceding advice: ?As the means to access rows in a table: You will read the index to get to a row in the table. Here you want to access a very small percentage of the rows in the table.

?As the means to answer a query: The index contains enough information to answer the entire query—we will not have to go to the table at all. The index will be used as a thinne r version of the table.

There are other ways as well—for example, we could be using an index to retrieve all of the rows in a table, including columns that are not in the index itself. That seemingly goes counter to both rules just presented. The case in which that would be true would be an interactive application where you are getting some of the rows and displaying them, then some more, and so on. You want to have the query optimized for initial response time, not overall throughput.

The first case (i.e., use the index if you are going to access a small percentage of the table) says if you have a table T (using the same table T from earlier) and you have a query plan that looks like this

ops$tkyte%ORA11GR2> set autotrace traceonly explain

ops$tkyte%ORA11GR2> select owner, status

2 from t

3 where owner = USER;

Execution Plan

----------------------------------------------------------

Plan hash value: 1049179052

------------------------------------------------------------------

------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 2120 | 23320 |

| 1 | TABLE ACCESS BY INDEX ROWID |T | 2120 | 23320 |

| *2 | INDEX RANGE SCAN | DESC_T_IDX | 8 | |

------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access(SYS_OP_DESCEND("OWNER")=SYS_OP_DESCEND(USER@!))

filter(SYS_OP_UNDESCEND(SYS_OP_DESCEND("OWNER"))=USER@!)

you should be accessing a very small percentage of this table. The issue to look at here is the INDEX (RANGE SCAN) followed by the TABLE ACCESS BY INDEX ROWID. This means that Oracle will read the index and then, for the index entries, it will perform a database block read (logical or physical I/O) to get the row data. This is not the most efficient method if you are going to have to access a large percentage of the rows in T via the index (we will soon define what a large percentage might be).

In the second case (i.e., when the index can be used instead of the table), you can process 100 percent (or any percentage, in fact) of the rows via the index. You might use an index just to create a thinner version of a table. The following query demonstrates this concept:

ops$tkyte%ORA11GR2> select count(*)

2 from t

3 where owner = user;

Execution Plan

----------------------------------------------------------

Plan hash value: 293504097

---------------------------------------------------------------------------

---------------------------------------------------------------------------

| 0 | SELECT STA TEMENT | | 1 | 6 | 17 (0) | 00:00:01 |

| 1 | SORT AGGREGAT E | | 1 | 6 | .. | .|

| * 2 | INDEX RANGE SCAN | T_IDX | 2 120 | 12720 | 17 (0) | 00: 00: 01 |

---------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - access("OWNER"=USER@!)

Here, only the index was used to answer the query—it would not matter now what percentage of rows we were accessing, as we would use the index only. We can see from the plan that the underlying table was never accessed; we simply scanned the index structure itself.

It is important to understand the difference between the two concepts. When we have to do a TABLE ACCESS BY INDEX ROWID, we must ensure we are accessing only a small percentage of the total blocks in the table, which typically equates to a small percentage of the rows, or that we need the first rows to be retrieved as fast as possible (the end user is waiting for them impatiently). If we access too high a percentage of the rows (larger than somewhere between 1 and 20 percent of the rows), then it will generally take longer to access them via a B*Tree than by just full scanning the table.

With the second type of query, where the answer is found entirely in the index, we have a different story. We read an index block and pick up many rows to process, then we go on to the next index block, and so on—we never go to the table. There is also a fast full scan we can perform on indexes to make this even faster in certain cases. A fast full scan is when the database reads the index blocks in no particular order; it just starts reading them. It is no longer using the index as an index, but even more like a table at that point. Rows do not come out ordered by index entries from a fast full scan.

In general, a B*Tree index would be placed on columns that we use frequently in the

predicate of a query, and we would expect some small fraction of the data from the table to be returned or the end user demands immediate feedback. On a thin table (i.e., a table with few or small columns), this fraction may be very small. A query that uses this index should expect to retrieve 2 to 3 percent or less of the rows to be accessed in the table. On a fat table (i.e., a table with many columns or very wide columns), this fraction might go all the way up to 20 to 25 percent of the table. This advice doesn’t always seem to make sense to everyone immediately; it is not intuitive, but it is accurate. An index is stored sorted by index key. The index will be accessed in sorted order by key. The blocks that are pointed to are stored randomly in a heap. Therefore, as we read through an index to access the table, we will perform lots of scattered, random I/O. By “scattered,”I mean that the index will tell us to read block 1, block 1,000, block 205, block 321, block 1, block 1,032, block 1, and so on—it won’t ask us to read block 1, then block 2, and then block 3 in a consecutive manner. We will tend to read and reread blocks in a very haphazard fashion. This single block I/O can be very slow.

As a simplistic example of this, let’s say we are reading that thin table via an index, and we are going to read 20 percent of the rows. Assume we have 100,000 rows in the table. Twenty percent of that is 20,000 rows. If the rows are about 80 bytes apiece in size, on a database with an 8KB block size, we will find about 100 rows per block. That means the table has approximately 1,000 blocks. From here, the math is very easy. We are going to read 20,000 rows via the index; this will mean quite likely 20,000 TABLE ACCESS BY ROWID operations. We will process 20,000 table blocks to execute this query. There are only about 1,000 blocks in the entire table, however! We would end up reading and processing each block in the table on average 20 times. Even if we increased the size of the row by an order of magnitude to 800 bytes per row, and 10 rows per block, we now have 10,000 blocks in the table. Index accesses for 20,000 rows would cause us to still read each block on average two times. In this case, a full table scan will be much more efficient than using an index, as it has to touch each block only once. Any query that used this index to access the data would not be very efficient until it accesses on average less than 5 percent of the data for the 800-byte column (then we access about 5,000 blocks) and even less for the 80-byte column (about 0.5 percent or less).

When Should Y ou Use a Bitmap Index?

Bitmap indexes are most appropriate on low distinct cardinality data (i.e., data with relatively few discrete values when compared to the cardinality of the entire set). It is not really possible to put a value on this—in other words, it is difficult to define what low distinct cardinality is truly. In a set of a couple thousand records, 2 would be low distinct cardinality, but 2 would not be low distinct cardinality in a two-row table. In a table of tens or hundreds of millions records, 100,000 could be low distinct cardinality. So, low distinct cardinality is relative to the size of the result set. This is data where the number of distinct items in the set of rows divided by the number of rows is a small number (near zero).For example, a GENDER column might take on the values M, F, and NULL. If you have a table with 20,000 employee records in it, then you would find that 3/20000 = 0.00015. Likewise, 100,000 unique values out of 10,000,000 results in a ratio of 0.01—again, very small. These columns would be candidates for bitmap indexes. They probably would not be candidates for a having B*Tree indexes, as each of the values would tend to retrieve an extremely large percentage of the table. B*Tree indexes should be selective in general, as outlined earlier.

Bitmap indexes should not be selective—on the contrary, they should be very unselective in general.

Bitmap indexes are extremely useful in environments where you have lots of ad hoc queries, especially queries that reference many columns in an ad hoc fashion or produce aggregations such as COUNT. For example, suppose you have a large table with three columns: GENDER, LOCATION, and AGE_GROUP. In this table, GENDER has a value of M or F, LOCATION can take on the values 1 through 50, and AGE_GROUP is a code representing 18 and under, 19-25, 26-30, 31-40, and 41 and over. You have to support a large number of ad hoc queries that take the following form:

Select count(*)

from T

where gender = 'M'

and location in ( 1, 10, 30 )

and age_group = '41 and over';

select *

from t

where ( ( gender = 'M' and location = 20 )

or ( gender = 'F' and location = 22 ))

and age_group = '18 and under';

select count(*) from t where location in (11,20,30);

select count(*) from t where age_group = '41 and over' and gender = 'F';

You would find that a conventional B*Tree indexing scheme would fail you. If you wanted to use an index to get the answer, you would need at least three and up to six combinations of possible B*Tree indexes to access the data via the index. Since any of the three columns or any subset of the three columns may appear, you would need large concatenated B*Tree indexes on ? GENDER, LOCA TION, AGE_GROUP: For queries that used all three, or GENDER with LOCATION, or GENDER alone

?LOCATION, AGE_GROUP: For queries that used LOCATION and AGE_GROUP or LOCATION alone

?AGE_GROUP, GENDER: For queries that used AGE_GROUP with GENDER or AGE_GROUP alone

To reduce the amount of data being searched, other permutations might be reasonable as well in order to decrease the size of the index structure being scanned. This is ignoring the fact that a B*Tree index on such low cardinality data is not a good idea.

Here is where the bitmap index comes into play. With three small bitmap indexes, one on each of the individual columns, you will be able to satisfy all of the previous predicates efficiently. Oracle will simply use the functions AND, OR, and NOT, with the bitmaps of the three indexes together, to find the solution set for any predicate that references any set of these three columns. It will take the resulting merged bitmap, convert the 1s into rowids if necessary, and access the data (if you are just counting rows that match the criteria, Oracle will just count the 1 bits). Let’s take a look at an example. First, we’ll generate test data that matches our specified distinct cardinalities, index it, and gather statistics. We’ll make use of the DBMS_RANDOM package to generate

random data fitting our distribution:

ops$tkyte%ORA11GR2> create table t

2 ( gender not null,

3 location not null,

4 age_group not null,

5 data

6 )

7 as

8 select decode( ceil(dbms_random.value(1,2)),

9 1, 'M',

10 2, 'F' ) gender,

11 ceil(dbms_random.value(1,50)) location,

12 decode( ceil(dbms_random.value(1,5)),

13 1,'18 and under',

14 2,'19-25',

15 3,'26-30',

16 4,'31-40',

17 5,'41 and over'),

18 rpad( '*', 20, '*')

19 from big_table.big_table

20 where rownum <= 100000;

Table created.

ops$tkyte%ORA11GR2> create bitmap index gender_idx on t(gender);

Index created.

ops$tkyte%ORA11GR2> create bitmap index location_idx on t(location);

Index created.

ops$tkyte%ORA11GR2> create bitmap index age_group_idx on t(age_group);

Index created.

ops$tkyte%ORA11GR2> exec dbms_stats.gather_table_stats( user, 'T');

PL/SQL procedure successfully completed.

Now we’ll take a look at the plans for our various ad hoc queries from earlier:

ops$tkyte%ORA11GR2> Select count(*)

2 from T

3 where gender = 'M'

4 and location in ( 1, 10, 30 )

5 and age_group = '41 and over';

Execution Plan

----------------------------------------------------------

Plan hash value: 1811480857

------------------------------------------------------------------------------------

------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 13 | 5 (0)|

| 1 | SORT AGGREGATE | | 1 | 13 | |

| 2 | BITMAP CONVERSION COUNT | | 1 | 13 | 5 (0)|

| 3 | BITMAP AND | | | | |

| 5 | BITMAP OR | | | | |

------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("GENDER"='M')

6 - access("LOCATION"=1)

7 - access("LOCATION"=10)

8 - access("LOCATION"=30)

9 - access("AGE_GROUP"='41 and over')

This example shows the power of the bitmap indexes. Oracle is able to see the location in (1,10,30) and knows to read the index on location for these three values and logically OR together the “bits”in the bitmap. It then takes that resulting bitmap and logically ANDs that with the bitmaps for AGE_GROUP='41 AND OVER' and GENDER='M'. Then a simple count of 1s and the answer is ready.

ops$tkyte%ORA11GR2> select *

2 from t

3 where ( ( gender = 'M' and location = 20 )

4 or ( gender = 'F' and location = 22 ))

5 and age_group = '18 and under';

Execution Plan

----------------------------------------------------------

Plan hash value: 906765108

---------------------------------------------------------------------------------

---------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 510 | 16830 |78 (0)|

| 1 | TABLE ACCESS BY INDEX ROWID | T | 510 | 16830 |78 (0)|

| 2 | BITMAP CONVERSION TO ROWIDS | | | | |

| 3 | BITMAP AND | | | | |

| 5 | BITMAP OR | | | | |

| 6 | BITMAP AND | | | | |

| 9 | BITMAP AND | | | | |

---------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

4 - access("AGE_GROUP"='18 and under')

7 - access("LOCATION"=22)

8 - access("GENDER"='F')

10 - access("GENDER"='M')

11 - access("LOCA TION"=20)

This shows similar logic: the plan shows the OR’d conditions are each evaluated by AND-ing together the appropriate bitmaps and then OR-ing together those results. Throw in another AND to satisfy the AGE_GROUP='18 AND UNDER' and we have it all. Since we asked for the actual rows this time, Oracle will convert each bitmap 1 and 0 into rowids to retrieve the source data.

In a data warehouse or a large reporting system supporting many ad hoc SQL queries, this ability to use as many indexes as make sense simultaneously comes in very handy indeed. Using conventional B*Tree indexes here would not be nearly as usual or usable, and as the number of columns that are to be searched by the ad hoc queries increases, the number of combinations of B*Tree indexes you would need increases as well.

However, there are times when bitmaps are not appropriate. They work well in a read-intensive environment, but they are extremely ill suited for a write-intensive environment. The reason is that a single bitmap index key entry points to many rows. If a session modifies the indexed data, then all of the rows that index entry points to are effectively locked in most cases. Oracle cannot lock an individual bit in a bitmap index entry; it locks the entire bitmap index entry. Any other modifications that need to update that same bitmap index entry will be locked out. This will seriously inhibit concurrency, as each update will appear to lock potentially hundreds of rows preventing their bitmap columns from being concurrently updated. It will not lock every row as you might think—just many of them. Bitmaps are stored in chunks, so using the earlier EMP example we might find that the index key ANAL YST appears in the index many times, each time pointing to hundreds of rows. An update to a row that modifies the JOB column will need to get exclusive access to two of these index key entries: the index key entry for the old value and the index key entry for the new value. The hundreds of rows these two entries point to will be unavailable for modification by other sessions until that UPDATE commits.

产品设计中英文文献

中文译文产品设计，语义和情绪反应摘要本文探讨了人体工程学理论与语义和情感容的设计问题。其目的是要找到以下问题的答案：如何设计产品引发人心中的幸福；怎样的产品属性能够帮助你们沟通积极的情绪，最后，如何通过产品唤起某种情绪。换言之，这是对“意义”——可以成为一个产品，旨在与用户在情感层面上进行“沟通”的调查。 1、介绍当代生活是促进社会和技术变革的代名词。同样，产品设计通过材料技术，生产技术，信息处理技术等工序的发展而正在迅速转变。在技术方面正在发生变化的速度和规模超出任何期望。数字革命的对象是逐步转向与我们互动成更小，更聪明的黑盒子，使我们很难理解这一机制或工作方法（博尔茨2000年）。因此，在设计时比以前不同的框架，参照社会变革，资源和能源节约，新出现的环境问题，以及客户导向的趋势（大平1995年，琼斯1997年）。因此，无论是通过广告和营销推动战略，或潮流，时尚和社会活动，从消费产品的用户的期望也已改变。功能性，吸引力，易于被使用中，可负担性，可回收性和安全性，预计所有已经存在于一个产品属性。用户希望有更多的日常用品。最近设计的趋势表明了用户对激励对象的倾向，提高他们的生活，帮助触发情绪，甚至唤起梦想（詹森1999年，阿莱西2000年）。詹森预计，梦会快到了，下面的数据为基础的社会，所谓的信息社会（1999年）。他还说，作为信息和智力正成为电脑和高科技，社会领域将放在一个人的能力还没有被自动然而新的价值：情绪。功能是越来越多的产品中理所当然的，同时用户也可以实现在寻找一个完全不同的欣赏水平。想象，神话和仪式（即情感的语言）会对我们的行为产生影响，从我们的购买决定，我们与他人（詹森1999年）的沟通。此外，哈立德（2001：196）指出这是决定购买，可瞬间的，因此客户的需求可以被创建，速度非常快，而其他需要长期建立了'。因此，情感和'影响'一般，都收到了最后一个（Velásquez1998）几年越来越多的关注。'影响'是指消费者的心理反应产品的符号学的容。情绪和影响途径，可以研究在许多不同的层次，都提供不同的见解。正如Velásquez指出，一些模型已经被提出来的领域和多种环境。一些例子，他给包括情绪来创建逼真的品质和性格（贝茨1994年，克莱恩和布隆伯格1999年，埃利奥特1992年，赖利1996）系统合成剂，大约在叙事情感（艾略特等人在Velásquez1998年）。原因，在情绪处理系统，依靠调解社会互动（Breazeal 在Velásquez1998年），该模型和体系结构，行为和学习情绪的影响（Ca?mero1997年，

建筑结构设计中英文对照外文翻译文献

中英文对照外文翻译 (文档含英文原文和中文翻译) Create and comprehensive technology in the structure global design of the building The 21st century will be the era that many kinds of disciplines technology coexists , it will form the enormous motive force of promoting the development of building , the building is more and more important too in global design, the architect must seize the opportunity , give full play to the architect's leading role, preside over every building engineering design well. Building there is the global design concept not new of architectural design,characteristic of it for in an all-round way each element not correlated with building- there aren't external environment condition, building , technical equipment,etc. work in coordination with, and create the premium building with the comprehensive new technology to combine together. The premium building is created, must consider sustainable development , namely future requirement , in other words, how save natural resources as much as possible, how about protect the environment that the mankind depends on for existence, how construct through high-quality between architectural design and building, in order to reduce building equipment use quantity and

包装设计外文翻译文献

包装设计外文翻译文献(文档含中英文对照即英文原文和中文翻译)

包装对食品发展的影响消费者对某个产品的第一印象来说包装是至关重要的，包括沟通的可取性，可接受性，健康饮食形象等。食品能够提供广泛的产品和包装组合，传达自己加工的形象感知给消费者，例如新鲜包装/准备，冷藏，冷冻，超高温无菌，消毒（灭菌），烘干产品。食物的最重要的质量属性之一，是它的味道，其影响人类的感官知觉，即味觉和嗅觉。味道可以很大程度作退化的处理和/或扩展存储。其他质量属性，也可能受到影响，包括颜色，质地和营养成分。食品质量不仅取决于原材料，添加剂，加工和包装的方法，而且其预期的货架寿命（保质期）过程中遇到的运输和储存条件的质量。越来越多的竞争当中，食品生产商，零售商和供应商；和质量审核供应商有着显著的提高食品质量以及急剧增加包装食品的选择。这些改进也得益于严格的冷藏链中的温度控制和越来越挑剔的消费者。保质期的一个定义是：在规定的贮存温度条件下产品保持其质量和安全性的时间。在保质期内，产品的生产企业对该产品质量符合有关标准或明示担保的质量条件负责，销售者可以放心销售这些产品，消费者可以安全使用。保质期不是识别食物等产品是否变质的唯一标准，可能由于存放方式，环境等变化物质的过早变质。所以食物等尽量在保质期未到期就及时食用。包装产品的质量和保质期的主题是在第3章中详细讨论。

包装为消费者提供有关产品的重要信息，在许多情况下，使用的包装和/或产品，包括事实信息如重量，体积，配料，制造商的细节，营养价值，烹饪和开放的指示，除了法律准则的最小尺寸的文字和数字，有定义的各类产品。消费者寻求更详细的产品信息，同时，许多标签已经成为多语种。标签的可读性会是视觉发现的一个问题，这很可能成为一个对越来越多的老年人口越来越重要的问题。食物的选择和包装创新的一个主要驱动力是为了方便消费者的需求。这里有许多方便的现代包装所提供的属性，这些措施包括易于接入和开放，处置和处理，产品的知名度，再密封性能，微波加热性，延长保质期等。在英国和其他发达经济体显示出生率下降和快速增长的一个相对富裕的老人人口趋势，伴随着更加苛刻的年轻消费者，他们将要求和期望改进包装的功能，如方便包开启（百货配送研究所，IGD）。对零售商而言存在有一个高的成本，供应和服务的货架体系。没有储备足够的产品品种或及时补充库存，特别是副食品，如鲜牛奶，可能导致客户不满和流失到竞争对手的商店，这正需要保证产品供应。现代化的配送和包装系统，允许消费者在购买食品时，他们希望在他们想任何时间地点都能享用。近几年消费者的选择已在急剧扩大。例如在英国，20世纪60年代和90年代之间在一般超市的产品线的数量从2000年左右上升到超过18000人（INCPEN）。自20世纪70年代以来，食品卫生和安全问题已成为日益重要的关注和选择食物的驱动力。媒体所关注的一系列问题，如使用化学添

土木工程外文文献翻译

专业资料学院：专业：土木工程姓名：学号：外文出处：Structural Systems to resist (用外文写) Lateral loads 附件：1.外文资料翻译译文；2.外文原文。

附件1：外文资料翻译译文抗侧向荷载的结构体系常用的结构体系若已测出荷载量达数千万磅重，那么在高层建筑设计中就没有多少可以进行极其复杂的构思余地了。确实，较好的高层建筑普遍具有构思简单、表现明晰的特点。这并不是说没有进行宏观构思的余地。实际上，正是因为有了这种宏观的构思，新奇的高层建筑体系才得以发展，可能更重要的是：几年以前才出现的一些新概念在今天的技术中已经变得平常了。如果忽略一些与建筑材料密切相关的概念不谈，高层建筑里最为常用的结构体系便可分为如下几类： 1.抗弯矩框架。 2.支撑框架，包括偏心支撑框架。 3.剪力墙，包括钢板剪力墙。 4.筒中框架。 5.筒中筒结构。 6.核心交互结构。 7. 框格体系或束筒体系。特别是由于最近趋向于更复杂的建筑形式，同时也需要增加刚度以抵抗几力和地震力，大多数高层建筑都具有由框架、支撑构架、剪力墙和相关体系相结合而构成的体系。而且，就较高的建筑物而言，大多数都是由交互式构件组成三维陈列。将这些构件结合起来的方法正是高层建筑设计方法的本质。其结合方式需要在考虑环境、功能和费用后再发展，以便提供促使建筑发展达到新高度的有效结构。这并

不是说富于想象力的结构设计就能够创造出伟大建筑。正相反，有许多例优美的建筑仅得到结构工程师适当的支持就被创造出来了，然而，如果没有天赋甚厚的建筑师的创造力的指导，那么，得以发展的就只能是好的结构，并非是伟大的建筑。无论如何，要想创造出高层建筑真正非凡的设计，两者都需要最好的。虽然在文献中通常可以见到有关这七种体系的全面性讨论，但是在这里还值得进一步讨论。设计方法的本质贯穿于整个讨论。设计方法的本质贯穿于整个讨论中。抗弯矩框架抗弯矩框架也许是低，中高度的建筑中常用的体系，它具有线性水平构件和垂直构件在接头处基本刚接之特点。这种框架用作独立的体系，或者和其他体系结合起来使用，以便提供所需要水平荷载抵抗力。对于较高的高层建筑，可能会发现该本系不宜作为独立体系，这是因为在侧向力的作用下难以调动足够的刚度。我们可以利用STRESS，STRUDL 或者其他大量合适的计算机程序进行结构分析。所谓的门架法分析或悬臂法分析在当今的技术中无一席之地，由于柱梁节点固有柔性，并且由于初步设计应该力求突出体系的弱点，所以在初析中使用框架的中心距尺寸设计是司空惯的。当然，在设计的后期阶段，实际地评价结点的变形很有必要。支撑框架支撑框架实际上刚度比抗弯矩框架强，在高层建筑中也得到更广泛的应用。这种体系以其结点处铰接或则接的线性水平构件、垂直构件和斜撑构件而具特色，它通常与其他体系共同用于较高的建筑，并且作为一种独立的体系用在低、中高度的建筑中。

环境设计城市与景观毕业设计外文翻译中英文

I. City and The Landscape (1) Overview of Landscape Design Landscape design, first, is a people's thinking activity, performed as an art activity.Diversified thoughts formed complex diverse landscape art style. Contemporary landscape design apparently see is the diversity of the landscape forms,in fact its essence is to keep the closing up to the natural order system, reflected the more respect for human beings, more in-depth perspective of the nature of human's reality and need, not to try to conquer the nature.it is not even imitating natural, but produce a sense of belonging. Landscape is not only a phenomenon but the human visual scene. So the earliest landscape implications is actually city scene. Landscape design and creation is actually to build the city. (2) The Relationship Between Landscape and Urban City is a product of human social, economic and cultural development, and the most complex type. It is vulnerable to the artificial and natural environmental conditions of interference. In recent decades, with worldwide the acceleration of urbanization, the urban population intensive, heavy traffic, resource shortage,

产品设计外文文献及翻译

英文原文 Modern product design ---Foreign language translation original text With the growing of economices and the developing of technologies, the essential definition of Industral Design has been deepening while its extension meaning enlarging,which resulted in the transformation and renovation of some original design theories and concepts. In the new IT epoch, the contents, methodologies, concepts etc. of design have taken a great change from what they were before.However,the method of comparison and analysis is always playing a plvotal role, during the whole process of maintaining the traditional quintessence and innovating novel conceptions. 1.1 Traditional Design Traditional industrial design and product development mainly involved to three fields,vis.Art, Engineering and Marketing. The designers, who worked in the art field, always had outstanding basic art skills and visual sketching expression capacity as well as plentiful knowledge on ergonomics and aesthetics . So they could easily solve the problems of products about art . Works in the area of the project engineer with strong technical background, they used the method of logical analysis, you can design a detailed, in line with the requirements of the drawings of a total production, manufacture use. They can you good solution to the technical aspects of products. However, they often overlook the aesthetics of products that do not pay attention to fashion and cost-effective products in the market. In the field of commercial marketing staff proficient in the knowledge economy, will use marketing theory to predict customer behavior, they focus on products in the market development trends, but do not understand aesthetic and technical aspects of the problem. In a traditional industrial product design process, the three areas of general staff in their respective areas of independent work. Product engineers solve the technical problems so that products with the necessary functional and capable of producing manufactured, the product is "useful." Designers are using aesthetics,

框架结构设计外文翻译

毕业设计(论文)外文资料翻译系：机械工程系专业：土木工程姓名：学号：外文出处：Design of prestressed (用外文写) concrete structures 附件： 1.外文资料翻译译文；2.外文原文。

附件1：外文资料翻译译文 8-2简支梁布局一个简单的预应力混凝土梁由两个危险截面控制：最大弯矩截面和端截面。这两部分设计好之后，中间截面一定要单独检查，必要时其他部位也要单独调查。最大弯矩截面在以下两种荷载阶段为控制情况，即传递时梁受最小弯矩M G的初始阶段和最大设计弯矩M T时的工作荷载阶段。而端截面则由抗剪强度、支承垫板、锚头间距和千斤顶净空所需要的面积来决定。所有的中间截面是由一个或多个上述要求，根它们与上述两种危险截面的距离来控制。对于后张构件的一种常见的布置方式是在最大弯矩截面采用诸如I形或T形的截面，而在接近梁端处逐渐过渡到简单的矩形截面。这就是人们通常所说的后张构件的端块。对于用长线法生产的先张构件，为了便于生产，全部只用一种等截面，其截面形状则可以为I形、双T形或空心的。在第5 、 6 和7章节中已经阐明了个别截面的设计，下面论述简支梁钢索的总布置。梁的布置可以用变化混凝土和钢筋的办法来调整。混凝土的截面在高度、宽度、形状和梁底面或者顶面的曲率方面都可以有变化。而钢筋只在面积方面有所变化，不过在相对于混凝土重心轴线的位置方面却多半可以有变化。通过调整这些变化因素，布置方案可能有许多组合，以适应不同的荷载情况。这一点是与钢筋混凝土梁是完全不同的，在钢筋混凝土梁的通常布置中，不是一个统一的矩形截面便是一个统一的T形，而钢筋的位置总是布置得尽量靠底面纤维。首先考虑先张梁，如图 8-7，这里最好采用直线钢索，因为它们在两个台座之间加力比较容易。我们先从图（a）的等截面直梁的直线钢索开始讨论。这样的布置都很简单，但这样一来，就不是很经济的设计了，因为跨中和梁端的要求会产生冲突。通常发生在跨度中央的最大弯矩截面中的钢索，最好尽量放低，以便尽可能提供最大力臂而提供最大的内部抵制力矩。当跨度中央的梁自重弯矩M G相当大时，就可以把c.g.s布置在截面核心范围以下很远的地方，而不致在传递时在顶部纤维中引起拉应力。然而对于梁端截面却有一套完全不同的要求。由于在梁端没有外力矩，因为在最后的时刻，安排钢索要以c.g.s与 c.g.c在结束区段一致，如此同样地获得克服压力分配的方法。无论如何，如果张应力在最后不能承受，放置 c.g.s.

建筑景观语言(英文翻译)

Cover封面 Content目录 Design Explanation设计说明 Master Plan总平面 Space Sequence Analysis景观空间分析 Function Analysis功能分析 Landscape Theme Analysis景观景点主题分析图 Traffic Analysis交通分析 Vertical Plan竖向平面布置图 Lighting Furniture Layout灯光平面布置示意图 Marker/Background Music/Garbage Bin标识牌/背景音乐/垃圾桶布置图Plan平面图 Hand Drawing手绘效果图 Section剖面图 Detail详图 Central Axis中心公共主轴 Reference Picture参考图片 Planting Reference Picture植物选样材料类： aluminum铝 asphalt沥青 alpine rock轻质岗石 boasted ashlars粗凿 ceramic陶瓷、陶瓷制品 cobble小圆石、小鹅卵石 clay粘土 crushed gravel碎砾石 crushed stone concrete碎石混凝土 crushed stone碎石 cement石灰 enamel陶瓷、瓷釉 frosted glass磨砂玻璃 grit stone/sand stone砂岩 glazed colored glass/colored glazed glass彩釉玻璃 granite花岗石、花岗岩 gravel卵石 galleting碎石片 ground pavement material墙面地砖材料 light-gauge steel section/hollow steel section薄壁型钢 light slates轻质板岩 lime earth灰土 masonry砝石结构

机械设计外文翻译(中英文)

机械设计理论机械设计是一门通过设计新产品或者改进老产品来满足人类需求的应用技术科学。它涉及工程技术的各个领域，主要研究产品的尺寸、形状和详细结构的基本构思，还要研究产品在制造、销售和使用等方面的问题。进行各种机械设计工作的人员通常被称为设计人员或者机械设计工程师。机械设计是一项创造性的工作。设计工程师不仅在工作上要有创造性，还必须在机械制图、运动学、工程材料、材料力学和机械制造工艺学等方面具有深厚的基础知识。如前所诉，机械设计的目的是生产能够满足人类需求的产品。发明、发现和科技知识本身并不一定能给人类带来好处，只有当它们被应用在产品上才能产生效益。因而，应该认识到在一个特定的产品进行设计之前，必须先确定人们是否需要这种产品。应当把机械设计看成是机械设计人员运用创造性的才能进行产品设计、系统分析和制定产品的制造工艺学的一个良机。掌握工程基础知识要比熟记一些数据和公式更为重要。仅仅使用数据和公式是不足以在一个好的设计中做出所需的全部决定的。另一方面，应该认真精确的进行所有运算。例如，即使将一个小数点的位置放错，也会使正确的设计变成错误的。一个好的设计人员应该勇于提出新的想法，而且愿意承担一定的风险，当新的方法不适用时，就使用原来的方法。因此，设计人员必须要有耐心，因为所花费的时间和努力并不能保证带来成功。一个全新的设计，要求屏弃许多陈旧的，为人们所熟知的方法。由于许多人墨守成规，这样做并不是一件容易的事。一位机械设计师应该不断地探索改进现有的产品的方法，在此过程中应该认真选择原有的、经过验证的设计原理，将其与未经过验证的新观念结合起来。新设计本身会有许多缺陷和未能预料的问题发生，只有当这些缺陷和问题被解决之后，才能体现出新产品的优越性。因此，一个性能优越的产品诞生的同时，也伴随着较高的风险。应该强调的是，如果设计本身不要求采用全新的方法，就没有必要仅仅为了变革的目的而采用新方法。在设计的初始阶段，应该允许设计人员充分发挥创造性，不受各种约束。即使产生了许多不切实际的想法，也会在设计的早期，即绘制图纸之前被改正掉。只有这样，才不致于堵塞创新的思路。通常，要提出几套设计方案，然后加以比较。很有可能在最后选定的方案中，采用了某些未被接受的方案中的一些想法。

园林设计英文文献

Forests, Trees and Livelihoods, 2010, V ol. 19, pp. 319–340 ? 2010 A B Academic Publishers—Printed in Great Britain Which role for the non farm-sector in a forested landscape? lessons from Krui, indonesia Koen Kusters* University of Amsterdam and Center for International Forestry Research (CIFOR) abstract this article explores two interrelated premises. the first is that the non-farm sector is of increasing importance to rural household. the second is that non-farm growth reduces the pressure on natural resources. the article reports on an analysis of income trends in three villages in the Krui area, sumatra, Indonesia, by comparing household survey data from 1995 and 2004. Between these two years, neither the farm sector nor the non-farm sector showed sustained growth.Although the contribution of remittances to local incomes remained marginal, migration of unemployed and unmarried youngsters to urban areas has a positive effect on per capita incomes in the Krui area by decreasing the household size. With regard to the second premise the analysis shows that increased engagement in local non-farm activities does not automatically result in smaller landholdings. Increased engagement in ex-situ non-farm activities, however, helps to reduce pressure on local forest resources. introduction the mainstream debate on conservation and development is based on the assumptions that agriculture is both the main threat to conservation and the main engine for rural development. Consequently, a large body of literature exists on the possibilities to reform agriculture in such a way that it better fits conservation goals. two main approaches are promoted. the first is to support environmentally friendly agricultural systems such as agroforests, in addition to protected areas (scherr and Mcneely, 2003; Ashley et al., 2006). the second approach is to encourage agricultural intensification and to decrease pressure on protected areas by increasing the returns on existing agricultural land (Mellor, 2002; Green et al., 2005). Both approaches have practical problems. Agricultural systems with high biodiversity tend to be less productive than intensive agricultural systems (Van noordwijk et al., 1997) and may not be competitive when the opportunity cost of land and labour increases (Belcher et al., 2005). on the other hand, increasing the income per hectare of land through intensification can act as an incentive for agricultural expansion (Angelsen and Kaimowitz, 2001) and may create other environmental damage as well, for example through the overuse of *e-mail address: K.Kusters@uva.nl

设计类外文翻译

贯穿绿色工程的原则近年来,许多报纸、书籍、和会议的主题围绕出资行星上的负面影响,人类在其能力来维系生命。常,这些讨论,具体目标也应运而生,如,最大限度地减少浪费,接近可持续发展。目标语句可以提供非常有用的一个视觉所需要的实现,而且多数的这些的重要组成部分,有助于视力。然而,目标是当他们成为才生效。方法正在研制达到这些目标跨学门、工业、和部门。很明显,然而,这些方法目前既不系统也不全面。绿色工程()着重论述如何通过科学和技术能否实现可持续发展( )。原则的绿色工程(参见页),提供了一个框架下对科学家和从事在设计新材料、产品、过程和系统,是“良性”健康和环境。一个设计基于原则行走基线工程质量和安全规格以、经济、社会因素的影响。宽的适用性的原则是重要的。当处理设计建筑,不管它是化合物分子结构要求、产品体系结构,以创造一个汽车、城市新建筑的建造一个相同的绿色工程原则必须适用、有效和适当的。否则,这些不会原则,而是一个列表的技术,已经成功地特定条件下。在这篇文章中,我们说明这些原则可以应用在一系列的鳞片。也适用于查看原则在一个复杂的、完整的体系。就像每一个参数优化系统不能在任何一个时间,特别是当他们在,也是同样的道理这些原则。有一些案例表明,协同的成功应用的一个最重要的原则提出了一个或更多的其他人。在其他情况下,一个平衡的原则将再保险——优化系统整体解决方案。然而,也有一些两个基本概念应该努力整合在每:生命周期的考虑和第一的原则的绿色工程。生命周期和材料和能量的生命周期阶段进入每一个每一件产品和过程有他们自己的生活周期。如果一个产品是有益于环保但是由危险废物或不可再生物质,其基本上已被转移到另一边的整体生活周期。例如,如果一个产品或过程具有高效节能甚至能源发电(例如),但生产过程中影响程度抵消任何能量的收获,没有樊笼可持续发展优势。因此应该考虑的整个生命周期,包括物料及能源的投入。生命周期的物料及能源开始采集(例如,挖掘、钻孔、收获),然后移动整个制造,分销,使用,和结束的生命。这是必须考虑所有的申请时,是需要绿色工程的原则。这一策略的选择进行了补充,更能减低我们固有的良性输入在生命周期阶段的环境影响。使产品、过程和系统更有益于环保一般情况下遵循的两个基本方法:变化的内在属性的系统或改变的情况下条件时才能被感觉到的制度。虽然可能固有的毒性,降低;一个有条件的一种化学物质,包括控制变化的,以及是否接触,有毒化学物质。者优先,原因也是多方面的,最重要的是,以避免“失败”。依靠控制系统环境,如空气净化器或废水的处理,有一个潜在的失败,这可能导致重大危险到人健康和自然系统。然而,随着更多的良性设计,无论在条件或情况下,变化的本质系统不能失败。在这些情况下,该系统的固有属性是预先定义的,因此,它经常是很必要的,通过提高系统的变化情况和条件。虽然技术和经济因素的影响,往往可以排除通过系统设计具有更多的固有的良性、渐进性的变革在这种情况下,可以有很重大的影响,整个系统。选择一个之间的个人设计在最有益于环保和可持续的方式与设计了一个汽油发动的运动型多用途车是最能符合可持续发展。原则提供了一个绿色工程结构制造出和评估这些设计元素相关的最大限度的可持续发展。工程师可以使用这些原则为指导,以帮助确保设计的产品、过程或系统有基本的元件,条件,和被需要更稳定。原则虽然带来的负面影响的固有的有害物质(无论是毒理、乃至全球)可能会降到最低,这是

环境艺术设计外文翻译—城市景观设计中的生态规划

城市景观设计中的生态规划 Ecological planning in the urban landscape design 城市景观设计中的生态规划 Ecological planning in the urban landscape design Abstract: This article discusses the urban landscape from the relation of the following three concepts: the landscape, the city and the ecology. This paper mainly discusses how the landscape influences the city's living environment.The landscape is a stigma in the land, which is of the relationship between human and human, between man and nature. There exists some subtle relationship among landscape, city and humanized design. key word：Urban landscape、Living environment、Humanization I. City and The Landscape (1) Overview of Landscape Design Landscape design, first, is a people's thinking activity, performed as an art activity.Diversified thoughts formed complex diverse landscape art style. Contemporary landscape design apparently see is the diversity of the landscape forms,in fact its essence is to keep the closing up to the natural order system, reflected the more respect for human beings, more in-depth perspective of the nature of human's reality and need, not to try to conquer the nature.it is not even imitating natural, but produce a sense of belonging. Landscape is not only a phenomenon but the human visual scene. So the earliest landscape implications is actually city scene. Landscape design and creation is actually to build the city. (2) The Relationship Between Landscape and Urban City is a product of human social, economic and cultural development, and the most complex type. It is vulnerable to the artificial and natural environmental conditions of interference. In recent decades, with worldwide the acceleration of urbanization, the urban population intensive, heavy traffic, resource shortage, environment pollution and ecology deterioration has become the focus of attention of the human society. In the current environment condition in our country, the problem is very serious. and in some urban areas, the pollution has quite serious, and greatly influenced and restricts the sustainable development of the city. Landscape is the relationship between man and man, man and nature. This is, in fact, a kind of human living process. Living process is actually with the powers of nature and the interaction process, in order to obtain harmonious process. The landscape is

工业设计外文翻译

Interaction design Moggridge Bill Interaction design，Page 1-15 USA Art Press, 2008 Interaction design (IxD) is the study of devices with which a user can interact, in particular computer users. The practice typically centers on "embedding information technology into the ambient social complexities of the physical world."[1] It can also apply to other types of non-electronic products and services, and even organizations. Interaction design defines the behavior (the "interaction") of an artifact or system in response to its users. Malcolm McCullough has written, "As a consequence of pervasive computing, interaction design is poised to become one of the main liberal arts of the twenty-first century." Certain basic principles of cognitive psychology provide grounding for interaction design. These include mental models, mapping, interface metaphors, and affordances. Many of these are laid out in Donald Norman's influential book The Psychology of Everyday Things. As technologies are often overly complex for their intended target audience, interaction design aims to minimize the learning curve and to increase accuracy and efficiency of a task without diminishing usefulness. The objective is to reduce frustration and increase user productivity and satisfaction. Interaction design attempts to improve the usability and experience of the product, by first researching and understanding certain users' needs and then designing to meet and exceed them. (Figuring out who needs to use it, and how those people would like to use it.) Only by involving users who will use a product or system on a regular basis will designers be able to properly tailor and maximize usability. Involving real users, designers gain the ability to better understand user goals and experiences. (see also: User-centered design) There are also positive side effects which include enhanced system capability awareness and user ownership. It is important that the user be aware of system capabilities from an early stage so that expectations regarding functionality are both realistic and properly understood. Also, users who have been active participants in a product's development are more likely to feel a sense of ownership, thus increasing overall satisfa. Instructional design is a goal-oriented, user-centric approach to creating training and education software or written materials. Interaction design and instructional design both rely on cognitive psychology theories to focus on how users will interact with software. They both take an in-depth approach to analyzing the user's needs and goals. A needs analysis is often performed in both disciplines. Both, approach the design from the user's perspective. Both, involve gathering feedback from users, and making revisions until the product or service has been found to be effective. (Summative / formative evaluations) In many ways, instructional