Previous Next
View PDF 9 Data Concurrency and Consistency
Previous Next
View PDF 第9章数据并发性和一致性
This chapter explains how Oracle Database maintains consistent data in a
multiuser database environment.
本章介绍了在多用户数据库环境中，Oracle数据库如何维护一致的数据。This chapter contains the following sections: 本章包含以下各节：
?Introduction to Data Concurrency and Consistency o Multiversion Read Consistency
o Locking Mechanisms
o ANSI/ISO Transaction Isolation Levels
?Overview of Oracle Database Transaction Isolation Levels o Read Committed Isolation Level
o Serializable Isolation Level
o Read-Only Isolation Level
?Overview of the Oracle Database Locking Mechanism o Summary of Locking Behavior
o Use of Locks
o Lock Modes
o Lock Conversion and Escalation
o Lock Duration
o Locks and Deadlocks
?Overview of Automatic Locks
o DML Locks
o DDL Locks
o System Locks
?Overview of Manual Data Locks
?Overview of User-Defined Locks ?数据并发和一致性介绍
o多版本读一致性
o锁定机制
o ANSI/ISO 事务隔离级别?Oracle 数据库事务隔离级别概述o读提交隔离级别
o可串行化隔离级别
o只读隔离级别
?数据库锁定机制概述
o锁定行为总结
o使用锁
o锁模式
o锁转换和锁升级
o锁持续时间
o锁和死锁
?自动锁的概述
o DML锁
o DDL锁
o系统锁
?手动数据锁概述
?用户定义的锁的概述
Introduction to Data Concurrency and Consistency 数据并发和一致性介绍
In a single-user database, a user can modify data without concern for other users modifying the same data at the same time. However, in a multiuser database, statements within multiple simultaneous transactions 在单用户的数据库中，用户可以修改数据，而不用担心其他用户在同一时间修改相同的数据。但是，在一个多用户的数据库中，多个事务内的语句可以同时更新相同的数据。同时执行的多个事务必须产生有意义且一致的结果。
can update the same data. Transactions executing simultaneously must
produce meaningful and consistent results. Therefore, a multiuser
database must provide the following:
因此，多用户数据库必须提供以下功能：
?Data concurrency, which ensures that users can access data at
the same time
?数据并发性，确保多个用户可以同时访问数据
?Data consistency, which ensures that each user sees a consistent view of the data, including visible changes made by the user's own transactions and committed transactions of other users ?数据一致性，确保每个用户看到数据的一致的视图，包括可以看到用户自己的事务所做的更改，和其他用户已提交的事务所做的更改。
To describe consistent transaction behavior when transactions run concurrently, database researchers have defined a transaction isolation
model called serializability. A serializable transaction operates in an environment that makes it appear as if no other users were modifying
data in the database. 为描述当多个事务同时运行时的事务一致性行为，数据库研究人员定义了一种称为可串行性的事务隔离模型。可串行化事务在一种使其看起来好像没有其他用户正在修改数据库中的数据的环境中运作。
While this degree of isolation between transactions is generally desirable,
running many applications in serializable mode can seriously compromise application throughput. Complete isolation of concurrently running
transactions could mean that one transaction cannot perform an insertion into a table being queried by another transaction. In short, real-world considerations usually require a compromise between perfect transaction isolation and performance. 虽然事务之间的这种隔离度好像不错，但在可序列化模式下运行许多应用程序可能会严重影响应用程序吞吐量。对并发运行事务的完全隔离可能意味着一个事务无法在某个正在被另一个事务查询的表上执行插入操作。简而言之，现实的考虑通常需要在完美的事务隔离性和性能之间的一个折衷。
Oracle Database maintains data consistency by using a multiversion consistency model and various types of locks and transactions. In this way, the database can present a view of data to multiple concurrent users, with each view consistent to a point in time. Because different versions of data blocks can exist simultaneously, transactions can read the version of data committed at the point in time required by a query and return results that are consistent to a single point in time. Oracle 数据库通过使用多版本一致性模型和各种类型的锁和事务，来维护数据的一致性。通过这种方式，数据库可以向多个并发用户呈现一个数据的视图，每个视图都在某个时间点上是一致的。因为不同版本的数据块可以同时存在，事务可以读取在某个查询请求时间点上的已提交版本数据，并返回符合一个单一时间点的结果。
See Also: 另见：
Chapter 5, "Data Integrity" and Chapter 10, "Transactions"第 5 章，"数据完整性"和第 10 章，"事务" Multiversion Read Consistency 多版本读一致性
In Oracle Database, multiversioning is the ability to simultaneously materialize multiple versions of data. Oracle Database maintains multiversion read consistency, which means that database queries have the following characteristics: 在Oracle数据库中，多版本即同时实现数据的多个版本的能力。Oracle 数据库维护多版本读取一致性，这意味着数据库查询具有以下特征：
?Read-consistent queries ?读一致查询
The data returned by a query is committed and consistent with
respect to a single point in time.
查询所返回的数据已提交的，且关于某个单一时间点一致。
Important: 重要：
Oracle Database never permits dirty reads, which occur when a transaction reads uncommitted data in another transaction. Oracle 数据库绝不允许脏读。当一个事务读取了另一个事务中未提交的数据时，会发生脏读。
To illustrate the problem with dirty reads, suppose one transaction updates a column value without committing. A second transaction reads the updated and dirty (uncommitted) value. The first session rolls back the transaction so that the column has its old value, but the second transaction proceeds using the updated value, corrupting the database. Dirty reads compromise data integrity, violate foreign keys, and ignore unique constraints. 为说明脏读的问题，假设一个事务更新某列的值，但不提交。第二个事务读取此已更新的脏（未提交）值。第一个会话回滚了事务，使该列仍具有其旧值，但第二个事务继续使用更新的值，这会损坏数据库。脏读会破坏数据的完整性、破坏外键、和忽略唯一约束。
?Nonblocking queries ?非阻塞查询
Readers and writers of data do not block one another (see "Summary of Locking Behavior"). 数据的读取者和写入者不会相互阻塞（请参见"锁定行为总结"）。
Statement-Level Read Consistency 语句级读取一致性
Oracle Database always enforces statement-level read consistency,
which guarantees that data returned by a single query is committed and consistent with respect to a single point in time. The point in time to
which a single SQL statement is consistent depends on the transaction
isolation level and the nature of the query: Oracle 数据库始终强制执行语句级读取一致性，保证单个查询所返回的数据是已提交的、且关于某个单一时间点一致。单个 SQL 语句所一致的时间点取决于事务的隔离级别和查询的性质：
?In the read committed isolation level, this point is the time at which the statement was opened. For example, if a SELECT statement opens at SCN 1000, then this statement is consistent to SCN 1000. ?在读提交隔离级别，该时间点是语句打开的时间。例如，如果一个SELECT 语句在SCN 1000时打开，则此语句一致于SCN 1000。
?In a serializable or read-only transaction this point is time the transaction began. For example, if a transaction begins at SCN
1000, and if multiple SELECT statements occur in this transaction, then each statement is consistent to SCN 1000. ?在可串行化或只读事务隔离级别，该时间点为事务开始的时间。例如，如果一个事务开始于SCN 1000，且在该事务中有多个 SELECT 语句发生，则每个语句都一致于SCN 1000。
?In a Flashback Query operation (SELECT ... AS OF), the SELECT statement explicitly specifies the point in time. For
example, you can query a table as it appeared last Thursday at 2 p.m. ?在闪回查询操作（SELECT ... AS OF）中，SELECT 语句显式指定时间点。例如，你可以查询某个表在上星期四下午 2 时的数据
See Also: 另见：
Oracle Database Advanced Application Developer's Guide to learn about
Flashback Query
《Oracle 数据库高级应用开发指南》了解闪回查询Transaction-Level Read Consistency 事务级读取一致性
Oracle Database can also provide read consistency to all queries in a transaction, known as transaction-level read consistency. In this case, each statement in a transaction sees data from the same point in time, which is the time at which the transaction began. Oracle 数据库还可以为一个事务中的所有查询提供读取一致性，这称为事务级读取一致性。在这种情况下，事务中的每个语句都看到来自同一时间点（即该事务开始的时间）的数据。
Queries made by a serializable transaction see changes made by the transaction itself. For example, a transaction that updates employees and then queries employees will see the updates. Transaction-level read consistency produces repeatable reads and does not expose a query
to phantom reads. 在一个可序列化事务中的多个查询，能看到事务本身所做的更改。例如，某个事务更新了employees表，然后其后续查询将看到对employees所做的更新。事务级读取一致性产生可重复的读取，且不会产生幻读读。
Read Consistency and Undo Segments 读取一致性及撤消
To manage the multiversion read consistency model, the database must create a read-consistent set of data when a table is simultaneously queried and updated. Oracle Database achieves this goal through undo data. 为管理多版本的读取一致性模型，当表同时被查询和更新时，数据库必须创建一组读取一致的数据。Oracle 数据库通过使用撤销数据实现了这一目标。
Whenever a user modifies data, Oracle Database creates undo entries,
which it writes to undo segments ("Undo Segments"). The undo segments
contain the old values of data that have been changed by uncommitted or recently committed transactions. Thus, multiple versions of the same data,
all at different points in time, can exist in the database. The database can
use snapshots of data at different points in time to provide read-consistent views of the data and enable nonblocking queries. 每当用户修改了数据，Oracle数据库会创建撤销条目，并写入到撤销段 ("撤销段"）。撤销段包含由未提交事务或最近提交的事务所更改的数据的旧值。因此，同一数据在各个不同时间点上的多个版本，都可以存在于数据库中。数据库可以使用在不同时间点的数据快照，来提供数据读取一致视图，并实现非阻塞查询。
Read consistency is guaranteed in single-instance and Oracle Real Application Clusters (Oracle RAC) environments. Oracle RAC uses a cache-to-cache block transfer mechanism known as Cache Fusion to transfer
read-consistent images of data blocks from one database instance to
another. 读取一致性在单实例和 Oracle 真正应用集群（Oracle RAC）环境中都可以得到保证。Oracle RAC 使用一种称为缓存融合的“缓存到缓存”的数据块传输机制，将一个数据库实例中的数据块读取一致映像传送到另一个实例中。
See Also: 另见：
?"Internal LOBs" to learn about read consistency mechanisms for
LOBs
?"内部 LOBs"了解 LOB的读取一致性机制
?Oracle Database 2 Day + Real Application Clusters Guide to learn
about Cache Fusion
?《Oracle 数据库 2 日 + 实际应用集群指南》了解缓存融合
Read Consistency: Example 读一致性：示例
Figure 9-1 shows a query that uses undo data to provide statement-level read consistency in the read committed isolation level. 图 9-1 显示了一个查询，在已提交读隔离级别使用撤销数据以提供语句级的读取一致性。
Figure 9-1 Read Consistency in the Read Committed Isolation
Level
图 9-1 在已提交读隔离级别的读取一致性
Description of "Figure 9-1 Read Consistency in the Read Committed Isolation Level"Description of "Figure 9-1 Read Consistency in the Read Committed Isolation Level"
As the database retrieves data blocks on behalf of a query, the database ensures that the data in each block reflects the contents of the block when the query began. The database rolls back changes to the block as needed to reconstruct the block to the point in time the query started processing. 当数据库为某个查询检索数据块时，数据库确保每个块中的数据反映了该查询开始时的内容。数据库根据需要回滚对数据块所做的更改，以将块重建到查询处理开始的状态。
The database uses a mechanism called an SCN to guarantee the order of transactions. As the SELECT statement enters the execution phase, the database determines the SCN recorded at the time the query began executing. In Figure 9-1, this SCN is 10023. Each query in the transaction must return committed data with respect to SCN 10023. 数据库使用一种称为SCN的机制，来保证事务的顺序。当SELECT 语句进入执行阶段时，数据库会确定查询开始执行时所记录的SCN。在图 9-1中，该SCN为10023。在事务中的每个查询必须返回在SCN 10023时的已提交数据。
In Figure 9-1, blocks with SCNs after 10023 indicate changed data, as shown by the two blocks with SCN 10024. The SELECT statement requires a version of the block that is consistent with committed changes. The database copies current data blocks to a new buffer and applies undo data to reconstruct previous versions of the blocks. These reconstructed data blocks are called consistent read (CR) clones. 在图 9-1中，其SCN大于10023的块具有已更改数据，如图中的两个具有SCN 10024的块所示。SELECT 语句需要一个与已提交更改块一致的版本。该数据库将当前数据块复制到新的缓冲区，并应用撤消数据，以重新构造块的早期版本。这些重建的数据块被称为一致读取 (CR) 克隆。
In Figure 9-1, the database creates two CR clones: one block consistent to
SCN 10006 and the other block consistent to SCN 10021. The database returns the reconstructed data for the query. In this way, Oracle Database
prevents dirty reads. 在图 9-1中，数据库创建了两个 CR 克隆：一个块与SCN 10006一致，而另一个块与SCN 10021 一致。数据库为查询返回重建的数据。通过这种方式，数据库可以防止脏读。
See Also: 另见：
"Database Buffer Cache" and "System Change Numbers (SCNs)""数据库缓冲区缓存"和"系统更改号 (SCNs) " Read Consistency and Transaction Tables 读取一致性和事务表
The database uses a transaction table, also called an interested transaction list (ITL), to determine if a transaction was uncommitted when the database began modifying the block. The block header of every segment block contains a transaction table. 数据库使用一个称为感兴趣事务列表(ITL)的事务表，来确定当数据库开始修改块时是否某个事务还未提交。每个段块的块头包含一个事务表。
Entries in the transaction table describe which transactions have rows locked and which rows in the block contain committed and uncommitted changes. The transaction table points to the undo segment, which provides information about the timing of changes made to the database. 事务表中的条目描述了哪些事务有被锁定的行，以及块中的哪些行包含提交和未提交的更改。事务表指向撤销段，提供对数据库所做的更改的时间相关信息。
In a sense, the block header contains a recent history of transactions that affected each row in the block. The INITRANS parameter of the CREATE TABLE and ALTER TABLE statements controls the amount of transaction history that is kept. 在某种意义上，块头包含影响块中每个行的事务的最近历史记录。CREATE TABLE和ALTER TABLE语句的INITRANS参数，控制被保留的交易历史记录条数。
See Also: 另见：
Oracle Database SQL Language Reference to learn about the INITRANS
parameter
《Oracle 数据库 SQL 语言参考》了解INITRANS参数Locking Mechanisms 锁定机制
In general, multiuser databases use some form of data locking to solve the problems associated with data concurrency, consistency, and integrity. Locks are mechanisms that prevent destructive interaction between transactions accessing the same resource. 通常，多用户数据库使用某种形式的数据锁定，来解决与数据并发性、一致性、和完整性相关的问题。锁是防止访问同一资源的事务之间的破坏性相互作用的机制。
See Also: 另见：
"Overview of the Oracle Database Locking Mechanism""数据库锁定机制概述" ANSI/ISO Transaction Isolation Levels ANSI/ISO 事务隔离级别
The SQL standard, which has been adopted by both ANSI and ISO/IEC, defines four levels of transaction isolation. These levels have differing degrees of impact on transaction processing throughput. 已由 ANSI 和 ISO/IEC 采纳的SQL 标准，定义了四个事务隔离级别。这些级别对事务处理吞吐量有不同程度的影响。
These isolation levels are defined in terms of phenomena that must be prevented between concurrently executing transactions. The preventable phenomena are: 这些隔离级别根据在同时运行的事务之间必须防止的现象来定义。可预防的现象有：
?Dirty reads ?脏读
A transaction reads data that has been written by another
transaction that has not been committed yet.
一个事务读取了已被另一个事务写入、但尚未提交的数据。?Nonrepeatable (fuzzy) reads ?不可重复（模糊）读
A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data. For example, a user queries a row and then later queries the same row, only to discover that the data has changed. 一个事务重新读取之前曾经读取过的数据，发现另一个已提交的事务已修改或删除了该数据。例如，用户查询某行，然后稍后又查询相同的行，却发现数据已更改。
?Phantom reads ?幻像读
A transaction reruns a query returning a set of rows that satisfies a search condition and finds that another committed transaction has inserted additional rows that satisfy the condition. 一个事务重新运行满足某搜索条件的查询，并返回一个行集，发现另一个已提交的事务已插入了满足搜索条件的其他行。
For example, a transaction queries the number of employees. Five minutes later it performs the same query, but now the number has increased by one because another user inserted a record for a new
hire. More data satisfies the query criteria than before, but unlike in 例如，一个事务查询雇员数目。五分钟后它执行相同的查询，但现在人数却增加了一个，这是因为另一个用户为一名新员工插入了一条记录。满足查询条件的数据比之前更多了，但与不可重复读不同，之前读取的数据不会变化。
a fuzzy read the previously read data is unchanged.
The SQL standard defines four levels of isolation in terms of the phenomena that a transaction running at a particular isolation level is permitted to experience. Table 9-1 shows the levels. 根据运行在某个特定的隔离级别的事务所允许发生的现象，SQL 标准定义了四个隔离级别。表 9-1 显示了这些级别。
Table 9-1 Preventable Read Phenomena by Isolation Level 表 9-1 在不同隔离级别下的可预防的读现象
Isolation Level Dirty Read Nonrepeatable
Read
Phantom Read Read uncommitted Possible Possible Possible
Read committed Not possible Possible Possible Repeatable read Not possible Not possible Possible Serializable Not possible Not possible Not possible 隔离级别脏读不可重复读幻像读
未提交读可能可能可能已提交读不可能可能可能可重复读不可能不可能可能可串行化不可能不可能不可能
Oracle Database offers the read committed (default) and serializable isolation levels. Also, the database offers a read-only mode. Oracle 数据库提供了已提交读（默认值）和可串行化隔离级别。另外，数据库也可以提供一种只读模式。
See Also: 另见：
?"Overview of Oracle Database Transaction Isolation Levels" to learn about read committed, serializable, and read-only isolation levels ?Oracle Database SQL Language Reference for a discussion of Oracle Database conformance to SQL standards ?"Oracle 数据库事务隔离级别概述"了解已提交读、可串行化、和只读隔离级别
?《Oracle 数据库 SQL 语言参考》关于Oracle数据库与SQL 标准的一致性的讨论
Overview of Oracle Database Transaction Isolation
Levels
Oracle 数据库事务隔离级别概述
Table 9-1 summarizes the ANSI standard for transaction isolation levels.
The standard is defined in terms of the phenomena that are either permitted or prevented for each isolation level. Oracle Database provides
the transaction isolation levels: 表 9-1 总结了事务隔离级别的ANSI 标准。该标准定义了在各个隔离级别所允许或必须防止的现象。Oracle 数据库提供如下事务隔离级别：
?Read Committed Isolation Level ?Serializable Isolation Level
?Read-Only Isolation Level ?已提交读隔离级别?可串行化隔离级别?只读隔离级别
See Also: 另见：
?Oracle Database Advanced Application Developer's Guide to learn
more about transaction isolation levels
?《Oracle 数据库高级应用开发指南》了解事务隔离级别的更多信息
?Oracle Database SQL Language Reference and Oracle Database PL/SQL Language Reference to learn about SET TRANSACTION ISOLATION LEVEL ?《Oracle 数据库 SQL 语言参考》和《Oracle 数据库 PL/SQL 语言参考》了解SET TRANSACTION ISOLATION LEVEL
Read Committed Isolation Level 读提交隔离级别
In the read committed isolation level, which is the default, every
query executed by a transaction sees only data committed before the query—not the transaction—began. This level of isolation is appropriate
for database environments in which few transactions are likely to conflict. 在（默认的）已提交读隔离级别中，事务中执行的每个查询，仅看到在查询开始之前提交的数据——而不是事务开始之前提交的数据。这一隔离级别适合于几乎不可能发生事务冲突的数据库环境。
A query in a read committed transaction avoids reading data that commits while the query is in progress. For example, if a query is halfway through a scan of a million-row table, and if a different transaction commits an update to row 950,000, then the query does not see this change when it reads row 950,000. However, because the database does not prevent other transactions from modifying data read by a query, other transactions may change data between query executions. Thus, a transaction that runs the same query twice may experience fuzzy reads and phantoms. 已提交读事务中的查询可以避免读取在查询过程中所提交的数据。例如，如果一个查询正扫描到一个百万行表的中间，而另一个不同的事务对第950000行提交了一个更新，但当查询读到第950000行时，它并不能看见这个变化。但是，因为数据库不会阻止其它事务修改一个查询所读取的数据，其他事务可能会在查询执行期间更改数据。因此，两次运行相同查询的事务可能会遇到模糊读取和幻像读取现象。
Read Consistency in the Read Committed Isolation Level 在已提交读隔离级别中的读取一致性
A consistent result set is provided for every query, guaranteeing data
consistency, with no action by the user. An implicit query, such as a query implied by a WHERE clause in an UPDATE statement, is guaranteed a consistent set of results. However, each statement in an implicit query
does not see the changes made by the DML statement itself, but sees the data as it existed before changes were made. 为每个查询提供一个一致的结果集，其目的是为了保证数据一致性，而无需用户采取任何行动。对于隐含的查询（如在一个UPDATE 语句中的 WHERE 子句），也同样可以保证其一致的结果集。但是，在隐式查询中的每个语句不会看到 DML 语句本身所做的更改，只能看到更改之前所存在的数据。
If a SELECT list contains a PL/SQL function, then the database applies statement-level read consistency at the statement level for SQL run within the PL/SQL function code, rather than at the parent SQL level. For example, a function could access a table whose data is changed and committed by another user. For each execution of the SELECT in the function, a new read-consistent snapshot is established. 如果SELECT 列表中包含一个PL/SQL 函数，则数据库在该PL/SQL 函数代码内运行的SQL所在语句级别（而不是在父SQL级别）上，应用语句级别读取一致性。例如，一个函数可能会访问某个表，其数据被另一个用户更改并提交。在SELECT语句中的每次函数运行，都会建立一个新的读一致性快照。
See Also: 另见：
"Subqueries and Implicit Queries""子查询和隐式查询" Conflicting Writes in Read Committed Transactions 在读提交事务中的写入冲突
In a read committed transaction, a conflicting write occurs when the transaction attempts to change a row updated by an uncommitted concurrent transaction, sometimes called a blocking transaction. The 在一个读已提交事务中，当事务尝试更改由另一个未提交并发事务（有时称为阻塞事务）所更新的行时，会发生写入冲突。读提交事务将等待阻塞事务结束并释放其行锁。有两个选项如下所示：
read committed transaction waits for the blocking transaction to end and release its row lock. The options are as follows:
?If the blocking transaction rolls back, then the waiting transaction proceeds to change the previously locked row as if the other
transaction never existed. ?如果阻塞事务回滚，正在等待的事务将继续并更改之前被锁定的行，就像另一个事务从未存在一样。
?If the blocking transaction commits and releases its locks, then the waiting transaction proceeds with its intended update to the newly changed row. ?如果阻塞事务提交并释放了锁，则正在等待的事务将对这个刚被更新的行继续其预定更新。
Table 9-2 shows how transaction 1, which can be either serializable or read committed, interacts with read committed transaction 2. Table 9-2 shows a classic situation known as a lost update (see "Use of Locks"). The update made by transaction 1 is not in the table even though
transaction 1 committed it. Devising a strategy to handle lost updates is an important part of application development. 表 9-2 显示了一个可能是可串行化的或已提交读的事务 1，如何与另一个已提交读的事务 2 进行交互。表 9-2 显示了一个称为丢失更新的典型情况（请参阅"使用锁定"）。事务 1 所作的更新不能在表中反映出来，即使事务1 已经提交它。制定一项策略以处理更新丢失是应用程序开发的一个重要部分。
Table 9-2 Conflicting Writes and Lost Updates in a READ
COMMITTED Transaction
表 9-2 在一个已提交读事务中的写入冲突和丢失更新Session 1 Session 2 Explanation 解释
SQL> SELECT last_name, salary FROM employees WHERE
last_name IN
('Banda','Greene','Hintz'); LAST_NAME SALARY
------------- ----------
Banda 6200 Greene 950 Session 1 queries the salaries for
Banda, Greene, and Hintz. No
employee named Hintz is found.
会话1查询Banda、Greene、和
Hintz的薪金。找不到名为 Hintz的任
何雇员。
SQL> UPDATE employees SET salary = 7000 WHERE last_name = 'Banda';
Session 1 begins a transaction by
updating the Banda salary. The
default isolation level for transaction
1 is READ COMMITTED.
会话1开始一个事务1，更新Banda
的薪金。事务 1 的默认隔离级别是已
提交读。
SQL> SET TRANSACTION ISOLATION
LEVEL READ COMMITTED;
Session 2 begins transaction 2 and
sets the isolation level explicitly to
READ COMMITTED.
会话2开始一个事务2，并将隔离级
别显式设置为已提交读。
SQL> SELECT last_name, salary FROM employees WHERE last_name IN('Banda','Greene','Hintz'); LAST_NAME SALARY
------------- ---------- Banda 6200 Greene 9500 Transaction 2 queries the salaries for
Banda, Greene, and Hintz. Oracle
Database uses read consistency to
show the salary for Banda before the
uncommitted update made by
transaction 1.
事务 2查询Banda、Greene和Hintz
的薪金。Oracle 数据库使用读取一致
性，显示事务 1 做出未提交更新前
Banda的薪金。
SQL> UPDATE employees
SET salary =9900
WHERE last_name = 'Greene'; Transaction 2 updates the salary for
Greene successfully because
transaction 1 locked only the Banda
row (see "Row Locks (TX)").
事务 2 成功更新Greene的薪金，因
为事务 1 只锁定了Banda所在的行
（请参阅"行锁 (TX)"）。
SQL> INSERT INTO employees (employee_id, last_name, email,hire_date, job_id) VALUES (210,'Hintz', 'JHINTZ', SYSDATE,'SH_CLERK');
Transaction 1 inserts a row for
employee Hintz, but does not
commit.
事务 1 为雇员Hintz插入一行，但不
提交。
SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');
LAST_NAME SALARY
------------- ----------
Banda 6200
Greene 9900
Transaction 2 queries the salaries for
employees Banda, Greene, and
Hintz.
Transaction 2 sees its own update to
the salary for Greene. Transaction 2
does not see the uncommitted
update to the salary for Banda or the
insertion for Hintz made by
transaction 1.
事务 2 查询Banda、Greene和Hintz
的薪金。
事务 2 看到它自己对Greene薪金的
更新。但事务 2 看不到由事务 1对
Banda薪金所做的未提交更新，或为
Hintz插入的新行。
SQL> UPDATE employees SET
salary =6300
WHERE last_name = 'Banda';
-- prompt does not return
Transaction 2 attempts to update
the row for Banda, which is currently
locked by transaction 1, creating a
co flicting write. Transaction 2 waits
until transaction 1 ends.
事务2试图更新当前被事务1 锁定的
Banda行，这会产生一个写入冲突。
事务 2 必须等待，直到事务1 结束。
SQL> COMMIT; Transaction 1 commits its work, 事务 1 提交其工作，以结束事务。
ending the transaction.
1 row updated. SQL> The lock on the Banda row is now
released, so transaction 2 proceeds
with its update to the salary for
Banda.
现在Banda行上的锁释放了，所以事
务2 得以继续，并完成对Banda薪金
的更新。
SQL> SELECT last_name, salary FROM employees WHERE last_name IN('Banda','Greene','Hintz'); LAST_NAME SALARY
------------- ---------- Banda 6300 Greene 9900
Hintz Transaction 2 queries the salaries for
employees Banda, Greene, and
Hintz. The Hintz insert committed by
transaction 1 is now visible to
transaction 2. Transaction 2 sees its
own update to the Banda salary.
事务 2 查询雇员Banda、Greene和
Hintz的薪酬。现在事务 1已提交了
所插入的Hintz行，并能被事务 2看
到。事务 2 也看到自己对Banda薪金
的更新。
COMMIT; Transaction 2 commits its work,
ending the transaction.
事务 2提交其工作，以结束事务。
SQL> SELECT last_name, salary FROM employees WHERE last_name IN ('Banda','Greene','Hintz'); LAST_NAME SALARY
------------- ---------- Banda 6300 Greene 9900
Hintz Session 1 queries the rows for
Banda, Greene, and Hintz. The
salary for Banda is 6300, which is
the update made by transaction 2.
The update of Banda's salary to
7000 made by transaction 1 is now
"lost."
会话 1 查询Banda、Greene、Hintz
的行。Banda的薪金是 6300，这是
事务 2 所作的更新。事务 1对Banda
的薪金改至 7000的更新现在"丢失"
了。
Serializable Isolation Level 可串行化隔离级别
In the serialization isolation level, a transaction sees only changes
committed at the time the transaction—not the query—began and changes made by the transaction itself. A serializable transaction operates in an environment that makes it appear as if no other users were
modifying data in the database. 在可串行化隔离级别，事务只看到自事务开始以来（而不是自查询以来）该事务本身所提交的更改。可串行化事务的运行环境，使其看起来好像没有其他用户在修改数据库中的数据。
Serializable isolation is suitable for environments: 可串行化隔离适合如下环境：
?With large databases and short transactions that update only a few
rows
?大型数据库中只更新少数几行的短事务
?Where the chance that two concurrent transactions will modify the
same rows is relatively low
?两个并发事务将修改相同的行的可能性相对较低?Where relatively long-running transactions are primarily read only ?较长时间运行的事务主要为只读事务
In serializable isolation, the read consistency normally obtained at the statement level extends to the entire transaction. Any row read by the transaction is assured to be the same when reread. Any query is
guaranteed to return the same results for the duration of the transaction, so changes made by other transactions are not visible to the query regardless of how long it has been running. Serializable transactions do not experience dirty reads, fuzzy reads, or phantom reads. 在可串行化隔离级别，在语句级别所获得的读取一致性通常延伸到整个事务范围。当重新读取在同一事务中之前读取的任何行时，保证结果相同。可以保证任何查询在该事务的持续期间返回相同的结果，因此其他事务所做的更改是不可见的，无论该查询已运行了多长时间。可串行化事务不会遇到脏读、模糊读取、或幻读。
Oracle Database permits a serializable transaction to modify a row only if changes to the row made by other transactions were already committed when the serializable transaction began. The database generates an error when a serializable transaction tries to update or delete data changed by a different transaction that committed after the serializable transaction began: Oracle 数据库允许可串行化事务修改行，只要当可序列化事务开始时，由其它事务对行所做更改已提交。当一个串行化事务试图更新或删除某数据，而该数据在串行化事务开始后被一个不同的事务更改并提交，则数据库将生成一个错误：
ORA-08177: Cannot serialize access for this transaction ORA-08177: Cannot serialize access for this transaction
When a serializable transaction fails with the ORA-08177 error, an application can take several actions, including the following: 当可序列化事务失败，产生ORA-08177 错误时，应用程序可以采取行动，包括以下几种：
?Commit the work executed to that point ?将所执行的工作提交到该点
?Execute additional (but different) statements, perhaps after rolling back to a savepoint established earlier in the transaction ?也许要先回滚到事务中之前建立的某保存点，然后执行一些其他额外的（不同）语句
?Roll back the entire transaction ?回滚整个事务
Table 9-3 shows how a serializable transaction interacts with other transactions. If the serializable transaction does not try to change a row committed by another transaction after the serializable transaction began, then a serialized access problem is avoided. 表 9-3 显示了一个可串行化事务与其它事务之间的交互。如果可串行化事务不会尝试更改由另一个事务在该可序列化事务开始后所提交的行，就可以避免串行化访问问题。
Table 9-3 Read Consistency and Serialized Access Problems in 表 9-3 可串行化事务中的读取一致性和串行化访问问题
Serializable Transactions
Session 1 Session 2 Explanation 解释
SQL> SELECT last_name, salary FROM employees WHERE last_name IN ('Banda','Greene','Hintz'); LAST_NAME SALARY
------------- ---------- Banda 6200 Greene 9500 Session 1 queries the salaries for
Banda, Greene, and Hintz. No
employee named Hintz is found.
会话1查询Banda、Greene、和
Hintz的薪酬。找不到名为 Hintz的任
何雇员。
SQL> UPDATE employees SET salary = 7000
WHERE last_name = 'Banda';
Session 1 begins transaction 1 by
updating the Banda salary. The
default isolation level for is READ
COMMITTED.
会话1开始一个事务1，更新Banda
的薪金。事务 1 的默认的隔离级别是
已提交读。
SQL> SET TRANSACTION ISOLATION
LEVEL SERIALIZABLE;
Session 2 begins transaction 2 and
sets it to the SERIALIZABLE
isolation level.
会话2开始一个事务2，并将隔离级
别显式设置为可序列化隔离级别。
SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');
LAST_NAME SALARY
------------- ----------
Banda 6200
Greene 9500
Transaction 2 queries the salaries for
Banda, Greene, and Hintz. Oracle
Database uses read consistency to
show the salary for Banda before the
uncommitted update made by
transaction 1.
事务 2查询Banda、Greene、和
Hintz的薪金。Oracle 数据库使用读
取一致性，显示事务 1 做出未提交更
新前Banda的薪金。
SQL> UPDATE employees
SET salary = 9900
WHERE last_name = 'Greene';
Transaction 2 updates the Greene
salary successfully because only the
Banda row is locked.
事务 2 成功更新Greene的薪金，因
为只有Banda行被锁定。
SQL> INSERT INTO employees (employee_id, last_name, email, hire_date, job_id) VALUES (210, 'Hintz', 'JHINTZ', SYSDATE, Transaction 1 inserts a row for
employee Hintz.
事务 1 为雇员Hintz插入一行。
'SH_CLERK');
SQL> COMMIT; Transaction 1 commits its ork,
ending the transaction.
事务 1 提交其工作，以结束事务。
SQL> SELECT last_name, salary FROM employees WHERE last_name IN ('Banda','Greene','Hintz'); LAST_NAME SALARY
------------- ---------- Banda 7000 Greene 9500
Hintz SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN('Banda','Greene','Hintz');
LAST_NAME SALARY
------------- ----------
Banda 6200
Greene 9900
Session 1 queries the salaries for
employees Banda, Greene, and Hintz
and sees changes committed by
transaction 1. Session 1 does not
see the uncommitted Greene update
made by transaction 2.
Transaction 2 queries the salaries for
employees Banda, Greene, and
Hintz. Oracle Database read
consistency ensures that the Hintz
insert and Banda update committed
by transaction 1 are not visible to
transaction 2. Transaction 2 sees its
own update to the Banda salary.
会话1查询雇员Banda、Greene、和
Hintz的薪金，只能看到由事务 1 提
交的更改。会话1不能看见会话2对
Greene所做的未提交更新。
事务 2 查询雇员Banda、Greene、和
Hintz的薪金。Oracle 数据库读取一
致性确保由事务 1所做的插入Hintz
行和对Banda行的更新，对事务2 不
可见。事务 2 只看到自己对Banda薪
金的更新。
COMMIT; Transaction 2 commits its work,
ending the transaction.
事务 2提交其工作，结束该事务。
SQL> SELECT last_name, salary FROM employees WHERE last_name IN ('Banda','Greene','Hintz'); LAST_NAME SALARY
------------- ---------- Banda 7000 Greene 9900
Hintz SQL> SELECT last_name, salary
FROM employees WHERE last_name
IN ('Banda','Greene','Hintz');
LAST_NAME SALARY
------------- ----------
Banda 7000
Greene 9900
Hintz
Both sessions query the salaries for
Banda, Greene, and Hintz. Each
session sees all committed changes
made by transaction 1 and
transaction 2.
两个会话分别查询雇员Banda,
Greene, 和 Hintz的薪金。每个会话
将看到事务 1 和事务2 作出的所有已
提交更改。
SQL> UPDATE employees SET salary
= 7100 WHERE last_name = 'Hintz'; Session 1 begins transaction 3 by
updating the Hintz salary. The
default isolation level for transaction
3 is READ COMMITTED.
会话1更新Hintz的薪金，开始事务
3。事务3的默认隔离级别是已提交
读。
SQL> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; Session 2 begins transaction 4 and
sets it to the SERIALIZABLE
isolation level.
会话2开始事务 4，并将其设置为可
串行化隔离级别。
SQL> UPDATE employees SET salary = 7200
WHERE last_name = 'Hintz'; -- prompt does not return Transaction 4 attempts to update
the salary for Hintz, but is blocked
because transaction 3 locked the
Hintz row (see "Row Locks (TX)").
Transaction 4 queues behind
transaction 3.
事务 4 尝试更新Hintz的薪金，但被
阻塞，因为事务 3 锁定了Hintz行
（请参阅"行锁定 (TX)"）。在事务队
列中，事务4排在事务3的后面。
SQL> COMMIT; Transaction 3 commits its update of
the Hintz salary, ending the
transaction. 事务3提交了它对Hintz工资的更新，以结束事务：。
UPDATE employees
SET salary = 7200
WHERE last_name = 'Hintz' *
ERROR at line 1:
ORA-08177: can't serialize access
for this transaction The commit that ends transaction 3
causes the Hintz update in
transaction 4 to fail with the ORA-
08177 error. The problem error
occurs because transaction 3
committed the Hintz update after
transaction 4 began.
结束事务3的提交导致事务4对
Hintz更新失败，导致 ORA-08177 错
误。该错误之所以发生，是因为事务
3是在事务4开始后提交的
SQL> ROLLBACK; Session 2 rolls back transaction 4,
which ends the transaction.
会话2回滚事务 4，结束该事务。
SQL> SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; Session 2 begins transaction 5 and
sets it to the SERIALIZABLE
isolation level.
会话2开始事务5 ，并将其设置为可
串行化隔离级别。
SQL> SELECT last_name, salary FROM employees WHERE last_name IN ('Banda','Greene','Hintz'); LAST_NAME SALARY
------------- ---------- Banda 7100 Greene 9500 Transaction 5 queries the salaries for
Banda, Greene, and Hintz. The Hintz
salary update committed by
transaction 3 is visible.
事务 5查询Banda、Greene、和
Hintz的薪金。事务 3 所提交的对
Hintz薪酬的更新是可见的。
Hintz 7100
SQL> UPDATE employees SET salary =7200
WHERE last_name = 'Hintz';
1 row updated. Transaction 5 updates the Hintz
salary to a different value. Because
the Hintz update made by
transaction 3 committed before the
start of transaction 5, the serialized
access problem is avoided.
Note: If a different transaction
updated and committed the Hintz
row after transaction transaction 5
began, then the serialized access
problem would occur again.
事务 5 将Hintz的薪金更新为一个不
同值。因为事务 3对Hintz的更新是
在事务5开始之前提交的，也就避免
了序列化的访问问题。
注意：如果某个其他事务在事务 5
开始后对Hintz行进行了更新并提
交，则串行化的访问问题又会出现。
SQL> COMMIT; Session 2 commits the update
without any problems, ending the
transaction. 会话2提交了更新，未遇到任何问题，并结束事务。
See Also: 另见："Overview of Transaction Control""事务控制概述" Read-Only Isolation Level 只读隔离级别
The read-only isolation level is similar to the serializable isolation level,
but read-only transactions do not permit data to be modified in the transaction unless the user is SYS. Thus, read-only transactions are not susceptible to the ORA-08177 error. Read-only transactions are useful for generating reports in which the contents must be consistent with
respect to the time when the transaction began. 只读隔离级别类似于可串行化隔离级别，但只读事务不允许数据在事务中被修改，除非该用户是SYS。因此，只读事务不会受到ORA-08177 错误的影响。只读事务可用于生成报表，其内容必须与事务开始时保持一致。
Oracle Database achieves read consistency by reconstructing data as needed from the undo segments. Because undo segments are used in a circular fashion, the database can overwrite undo data. Long-running
reports run the risk that undo data required for read consistency may have been reused by a different transaction, raising a snapshot too old error. Setting an undo retention period, which is the minimum amount of time that the database attempts to retain old undo data before overwriting it, appropriately avoids this problem. Oracle 数据库通过按需从撤销段重建数据，来实现读取一致性。因为撤消段是以一个循环方式使用的，数据库可以覆盖撤销数据。长时间运行的报表可能有一定的风险，读取一致性所需要的撤销数据，可能已被一个不同的事务重用，并抛出快照太旧（snapshot too old）错误。设置一个撤消保留期，即在旧数据被覆盖之前，数据库尝试保留撤消数据的最短时间，以期避免这一问题。
See Also: 另见：
?"Undo Segments"
?Oracle Database Administrator's Guide to learn how to set the undo retention period ?"回滚段"
?《Oracle 数据库管理员指南》了解如何设置撤消保留期
Overview of the Oracle Database Locking
Mechanism
数据库锁定机制概述
A lock is a mechanism that prevents destructive interactions, which are interactions that incorrectly update data or incorrectly alter underlying data structures, between transactions accessing shared data. Locks play a
crucial row in maintaining database concurrency and consistency. 锁是一种机制，用来防止多个共同访问共享数据的事务之间的破坏性交互，包括不正确地更新数据或不正确地更改基础数据结构。锁在维护数据库并发性和一致性当中扮演着一个关键的角色。
Summary of Locking Behavior 锁定行为总结
The database maintains several different types of locks, depending on the
operation that acquired the lock. In general, the database uses two types
of locks: exclusive locks and share locks. Only one exclusive lock can be obtained on a resource such as a row or a table, but many share locks
can be obtained on a single resource. 数据库维护几种不同类型的锁，这取决于获取锁的操作。一般地，数据库使用两种类型的锁：独占锁和共享锁。在一个资源（如行或表）上，只能获得一个独占锁，但在单个资源上可以获得很多共享锁。
Locks affect the interaction of readers and writers. A reader is a query of a resource, whereas a writer is a statement modifying a resource. The following rules summarize the locking behavior of Oracle Database for readers and writers: 锁会影响读取者与写入者的交互。读取者是一个对某种资源的查询语句，而写入者是一个对某个资源的修改语句。以下规则总结了Oracle 数据库中读取者和写入者的锁定行为：
? A row is locked only when modified by a writer. ?一行只有在被某个写入者修改时，才被锁定。
When a statement updates one row, the transaction acquires a lock
for this row only. By locking table data at the row level, the database minimizes contention for the same data. Under normal
circumstances the database does not escalate a row lock to the block or table level. 当一个语句更新某行时，事务只需要获取在该行上的锁。通过在行级别锁定表数据，数据库最小化对同一数据的争用。在正常情况下，数据库不会将行锁升级到块级或表级。
? A writer of a row blocks a concurrent writer of the same row. ?一行的写入者，会阻塞在同一行上的并发写入者。
If one transaction is modifying a row, then a row lock prevents a different transaction from modifying the same row simultaneously. 如果一个事务正在修改某行，则行锁可防止不同的事务同时修改同一行。
? A reader never blocks a writer. ?一个读取者永远不会阻塞一个写入者。
Because a reader of a row does not lock it, a writer can modify this row. The only exception is a SELECT ... FOR UPDATE 由于行的读取者不会将它锁定，所以一个写入者可以修改该行。唯一的例外是SELECT ... FOR UPDATE语句，它是一种特殊类型的
statement, which is a special type of SELECT statement that does
lock the row that it is reading.
SELECT语句，的确会锁定它正在读取的行。? A writer never blocks a reader. ?一个写入者绝不会阻塞一个读取者。
When a row is being changed by a writer, the database uses undo data data to provide readers with a consistent view of the row. 当一个行正在被某个写入者更改时，数据库使用撤销数据向读取者提供一个该行的一致视图。
Note: 注意：
Readers of data may have to wait for writers of the same data blocks in very special cases of pending distributed transactions. 在某些非常特殊的情况下，在挂起的分布式事务中，数据读取者可能需要等待相同数据块上的写入者。
See Also: 另见：
?Oracle Database SQL Language Reference to learn about SELECT ... FOR UPDATE
?Oracle Database Administrator's Guide to learn about distributed transactions ?《Oracle 数据库 SQL 语言参考》了解SELECT ... FOR UPDATE
?《Oracle 数据库管理员指南》了解分布式事务
Use of Locks 使用锁
In a single-user database, locks are not necessary because only one user is modifying information. However, when multiple users are accessing and modifying data, the database must provide a way to prevent concurrent modification of the same data. Locks achieve the following important database requirements: 在单用户数据库中，锁不是必需的，因为只有一个用户在修改信息。但是，当多个用户在访问和修改数据时，数据库必须提供一种方法，以防止对同一数据进行并发修改。锁实现了以下重要的数据库需求：
?Consistency ?一致性
The data a session is viewing or changing must not be changed by other sessions until the user is finished. 一个会话正在查看或更改的数据不能被其它会话更改，直到用户会话结束。
?Integrity ?完整性
The data and structures must reflect all changes made to them in
the correct sequence.
数据和结构必须按正确的顺序反映对他们所做的所有更改。
Oracle Database provides data concurrency, consistency, and integrity among transactions through its locking mechanisms. Locking is performed automatically and requires no user action. Oracle 数据库通过其锁定机制，提供在多个事务之间的数据并发性、一致性、和完整性。锁定将自动执行，并且不需要用户操作。
The need for locks can be illustrated by a concurrent update of a single row. In the following example, a simple web-based application presents the end user with an employee email and phone number. The application 对锁的需求，可以由对某个单一行的并发更新来说明。在下面的示例中，一个简单的基于 web 的应用程序，将某个雇员的电子邮件和电话号码呈现给最终用户。应用程序使用如下所示的UPDATE语句修改该数据：
uses an UPDATE statement such as the following to modify the data:
UPDATE employees
SET email = ?, phone_number = ? WHERE employee_id = ?
AND email = ?
AND phone_number = ? UPDATE employees
SET email = ?, phone_number = ? WHERE employee_id = ?
AND email = ?
AND phone_number = ?
In the preceding UPDATE statement, the email and phone number values in the WHERE clause are the original, unmodified values for the specified employee. This update ensures that the row that the application modifies was not changed after the application last read and displayed it to the user. In this way, the application avoids the lost update database problem in which one user overwrites changes made by another user, effectively losing the update by the second user (Table 9-2 shows an example of a lost update). 在前面的UPDATE语句中，WHERE子句中电子邮件和电话号码是某指定雇员的原始的、未经修改的值。此更新可确保应用程序修改的行，在应用程序之前读取并向用户显示后，没有被更改过。以这种方式，应用程序可避免丢失更新的数据库问题，即其中一个用户覆盖了另一个用户所做的修改，实际上丢失了第二个用户所做的更新（表 9-2 显示了一个丢失更新的示例）。
Table 9-4 shows the sequence of events when two sessions attempt to modify the same row in the employees table at roughly the same time. 表 9-4 显示两个会话在大致相同的时间，试图修改在雇员表中相同行的事件序列。
Table 9-4 Row Locking Example 表 9-4 行锁定实例
Time Session 1 Session 2 Explanation 解释
t0 SELECT employee_id, email,
phone_number
FROM hr.employees
WHERE last_name = 'Himuro';
EMPLOYEE_ID EMAIL PHONE_NUMBER
----------- ------- ------------
118 GHIMURO 515.127.4565 In session 1, the hr1 user queries
hr.employees for the Himuro
record and displays the
employee_id (118), email
(GHIMURO), and phone number
(515.127.4565) attributes.
在会话1中，用户hr1查询在表
hr.employees中的Himuro的记
录，并显示其员工ID(118)、电子
邮件（GHIMURO）、和电话号码
(515.127.4565) 等属性。
t1 SELECT employee_id, email,
phone_number
FROM hr.employees
WHERE last_name = 'Himuro';
EMPLOYEE_ID EMAIL PHONE_NUMBER
----------- ------- ------------ In session 2, the hr2 user queries
hr.employees for the Himuro
record and displays the
employee_id (118), email
(GHIMURO), and phone number
(515.127.4565) attributes.
在会话2中，用户 hr2查询在表
hr.employees中的 Himuro 的记
录，并显示其员工ID (118)、
（GHIMURO）和电话号码
(515.127.4565) 等属性。
概念结构设计和逻辑结构设计 一.系统概述 本系统通过调查从事医药产品的零售，批发等工作的企业，根据其具体情况设计医药销售管理系统。医药管理系统的设计和制作需要建立在调查的数据基础上，系统完成后预期希望实现药品基本信息的处理，辅助个部门工作人员工作并记录一些信息，一便于药品的销售和管理。通过此系统的功能，从事药品零售和批发等部门可以实现一些功能，如：基础信息管理，进货管理，库房管理，销售管理，财务统计，系统维护等。 二．概念结构设计 1.员工属性 2.药品属性 3.客户属性 4.供应商属性 5.医药销售管理系统E--R 图 三．逻辑结构设计 该设计概念以概念结构设计中的E--R 图为主要依据，设计出相关的整体逻辑结构，具体关系模型如下：（加下划线的表示为主码） 药品信息（药品编号，药品名称，药品类别，规格，售价，进价，有效期，生产日期，产地，备注） 供应商信息（供应商编号，供应商名称，负责人，） 员工 姓名 家庭地址 E-maill 电话 员工 编号 年龄 帐号
四．系统各功能模块如何现（数据流实图）；1.基本信息管理子系统 基本信息管理子系统 药品信息员工信息客户信息供应商信息2.库存管理子系统 库存管理子系 统 库存查询库存信息出入库登记库存报表3.销售管理子系统 销售管理 销售登记销售退货销售查询 4.信息预警子系统 信息预警 报废预警库存预警 5.财务统计子系统 财务统计 统计销售额打印报表 6.系统管理子系统
系统管理 权限管理修改密码系统帮助 五．数据库设计（E-R图，数据库表结构） 1.药品基本信息表 列名字段数据类型可否为空说明药品编号 药品名称 药品类别 规格 进价 有效期 生产日期 售价 产地 备注 2.员工基本信息表 列名字段数据类型可否为空说明员工编号 性别 身份证号 员工年龄
大数据项目可行性研究报告（发改立项备案+2013年最新案 例范文）详细编制方案 北京博思远略咨询有限公司投资研究部 二零一三年四月 目录 第一部分博思远略编制大数据项目可研报告思路 (3) 一、大数据项目必要性及可行性研究主要内容 (3) 二、大数据项目可行性研究贯彻国家可持续发展政策的基本要求 (3) 第二部分甲级资质单位编制大数据项目可行性研究报告大纲（2013发改委标准） (5)
第三部分关于大数据项目可研不同用途及编制重点差异的说明 (11) 一、大数据项目可研报告按用途分类构成 (11) 二、用于发改委立项的大数据项目可行性研究报告编制独特性说明 (11) 三、用于银行贷款的大数据项目可行性研究报告编制独特性说明 (12) 四、用于申请用地的大数据项目可行性研究报告编制独特性说明 (13) 五、用于IPO上市募投的大数据项目可研报告编制独特性说明 (15) 第四部分大数据项目可研编制热点问题与专家答疑集锦 (16) 一、企业在项目立项备案过程中需要做哪些工作来提高通过率？ (16) 二、哪些项目可行性研究报告需要具有发改委甲级资质的机构撰写？ (17) 三、大数据项目投资决策分为哪几个阶段，每个阶段博思远略可以提供哪些 服务？ (18) 五、大数据项目可行性研究报告审批流程及各阶段提交材料清单？ (19) 第五部分大数据项目可行性研究方案设计（市场前景+技术可行性+经济可行性） (21) 一、“申报单位及项目概况”部分编写要点说明 (21) 二、“发展规划、产业政策和行业准入分析”部分编写要点说明 (21) 四、“节能方案分析”部分编写要点说明 (22) 五、“建设用地、征地拆迁及移民安置分析”部分编写要点说明 (23) 六、“环境和生态影响分析”部分编写要点说明 (24) 七、“经济影响分析”部分编写要点说明 (25) 八、“社会影响分析”部分编写要点说明 (26) 第六部分大数据项目可行性研究报告范文节选（基于成功案例） (28) 一、项目建设投资估算方案 (28) 二、企业介绍说明（图形数据归纳直观化） (28) 三、项目总平面布置图设计方案（根据要求可做效果图） (29) 四、项目综合能耗方案设计 (30) 五、项目投资构成方案设计 (31) 六、项目设备选型方案设计 (33) 七、项目生产工艺流程方案设计 (35) 八、项目市场前景分析（基于大量数据） (36) 九、项目盈利模式分析 (38) 十、项目盈亏平衡分析 (38) 第七部分博思远略大数据项目可行性研究报告编制服务 (40)
数据中心建设项目可行性研究报告 数据中心建设项目可行性研究报告
目录 1概述 (4) 1.1项目背景 (4) 1.2项目意义 (4) 2建设目标与任务 (4) 3需求分析 (6) 3.1用户需求 (6) 3.2数据需求 (6) 3.2.1数据资源现状 (6) 3.3系统及应用需求分析 (10) 3.3.1节点管理 (12) 3.3.2主题管理 (12) 3.3.3元数据管理 (12) 3.3.4公共代码管理 (12) 3.3.5数据采集 (13) 3.3.6数据整理比对 (13) 3.3.7数据交换 (13) 3.3.8数据访问 (13) 3.3.9数据备份与恢复 (13) 3.3.10标准管理 (13) 3.3.11应用支持 (14) 3.3.12运行管理 (14) 3.4性能需求分析 (14) 3.4.1业务处理量分析 (14) 3.5安全保障体系需求分析 (16) 3.5.1系统安全可靠性需求 (16) 3.5.2数据安全保密性需求 (17) 3.5.3数据完整性需求 (17) 3.5.4实体的可鉴别性需求 (17) 3.5.5不可否认性需求 (17) 3.5.6对象和行为的可授权性需求 (17) 3.5.7统一信任与授权策略需求 (18) 3.5.8数据中心统一安全监管性需求 (18) 3.6保障机制需求分析 (18) 4数据中心设计方案 (19) 4.1设计原则 (19) 4.1.1统一建设 (19) 4.1.2相对独立 (19) 4.1.3共建共享 (19) 4.1.4安全可靠 (19) 4.2数据中心平台设计 (20) 4.2.1平台总体架构 (20)
第24卷第6期 2009年11 月The Jou rna l of Guangdong U n ive rsity of F inance Vol .24,No .6Nov .2009 经济资本、风险测度与保险公司的价值管理 杨明亮 中国再保险集团博士后科研工作站,北京100140 摘 要:传统的风险管理模式已经不能适应保险公司发展的需要。 经济资本管理已经成为国际保险业风险与资本管理领域的核心工具。保险公司经营的特殊性决定了保 险公司要实施经济资本管理。经济资本可以广泛地应用于内部资本充足率管理和价值创 造管理,为保险公司的关键决策提供依据。经济资本管理体系核心是准确计量风险、优化 资本配置与评估风险调整绩效。中国保险业要实施经济资本管理,必须要统一认识,整合 资源,优化组织结构,积极推动经济资本管理体系建设。 关键词:保险公司;经济资本;资本配置;价值管理 中图分类号:F840.32 文献标识码:A 文章编号:167421625(2009)0620111216 收稿日期:2009205221 作者简介:杨明亮(19722),陕西渭南人,应用经济学博士,现供职于中国再保险集团博士后工作站、西南财经大学博士后流动站(合作),研究方向为风险管理。 一、引言 经济资本管理是金融机构一致性评估风险,并以资本覆盖风险承担活动影响的方法和实践。自新巴塞尔协议推动银行业实施经济资本管理体系后,国际保险业也在这一领域做了诸多研究和探索,欧盟委员会、国际精算协会(I AA )、美国保险监督官协会(NA I C )等监管组织已经推出了相应的计划,要求或鼓励保险公司开发内部风险控制模型,实施经济资本管理。穆迪、标准普尔等主要评级机构也准备或已经将经济资本管理模型引入评级体系。在这一背景下,国际领先保险机构普遍建立或引进了经济资本模型,并将计算结果广泛地应用于管理实践,经济资本管理正在成为全球保险业全面风险管理的主流方法和核心机制。 对中国保险业而言,经济资本还是一个全新的概念。保险公司的资本管理主要基于监管规则计算,其目标是满足监管对偿付能力的要求,属于合规管理的范畴。保险公司的资本(最小偿付能力额度)是保费收入的一个固定比例,实际资本(偿付能力)则
2020年数据中心项目可行性研究报告 2020年7月
目录 一、项目概况 (3) 二、项目背景和必要性 (3) 1、顺应国家产业政策发展需求 (3) 2、优化公司产业链布局，促进公司在数据信息服务行业下游的延伸发展 (4) 3、增加营业收入，提高公司盈利水平 (4) 三、项目实施的可行性 (4) 1、国家和地方政策为项目提供有力支持 (4) 2、行业发展前景为项目提供市场保障 (5) 3、公司在技术、人员、市场等方面的储备为项目提供坚实基础 (6) （1）技术储备 (6) （2）人员储备 (7) （3）市场拓展能力 (7) 四、项目建设周期 (8) 五、项目投资概算 (8) 六、项目经济效益评价 (8)
一、项目概况 本项目拟建设2,800架标准服务器20A机柜，建成后提供机柜租用及运维服务等IDC基础服务。 二、项目背景和必要性 1、顺应国家产业政策发展需求 受“互联网+”、大数据战略、数字经济等国家政策指引以及移动互联网快速发展的驱动，加强包括数据中心在内的信息基础设施建设已上升为国家战略。2018年工信部印发《全国数据中心应用发展指引（2017）》以来，我国数据中心布局渐趋完善，新建数据中心，尤其是大型、超大型数据中心逐渐向西部以及北上广深周边地区转移。北京、上海、广州、深圳等一线城市数据中心规模增速放缓，其周边地区数据中心规模快速增长，网络质量、建设等级及运维水平进一步提升，逐步承接一线城市应用需求。 南京市地处长三角地区，涌现了一批大、中型互联网公司，近年来许多大型互联网公司也在南京设立区域总部。项目建设地处于南京市江宁开发区南京未来科技城，2018年8月南京市政府与国家信息中心签署战略合作协议，在南京未来科技城合作共建国家大数据（南京）基地，南京未来科技城作为江宁重点建设的科技创新载体和产业发展高地，聚焦网络通信和智能制造两大主导产业。本项目建设符合产业政策发展需要。
对VaR改进的一致性的风险度量尺度分析 【摘要】文章先对现有的风险度量尺度进行了简介，特别重点介绍了流行的VaR优点与缺点，以及后人对它的改进。在此基础上，文章针对VaR的不足构造了一种一致性的风险度量尺度AVaR。最后文章还对AVaR与VaR作了简单的比较。 【关键词】金融风险；风险度量尺度；VaR；AVaR 一、风险度量尺度简介 随着金融市场在近年来的快速发展，特别是金融工具创新的大量涌现，金融风险是当今金融领域最受关注的话题之一。为了更好地对金融风险进行预测和控制，学术界和金融领域的实际工作者相继提出了各种度量风险的尺度，从最早的收益的标准差到现在最热门的VaR。尽管方法很多，最常见的有以下六种： （1）标准差：； （2）半方差与下偏差Lbm[1]： ；，； （3）变异系数[2]：； （4）VaR：； （5) 右尾风险MEL与尾部VaR(TCE) [3]： , x为固定的目标值； （6）系数[4]：y代表市场指数。 （符号说明：上面的符号统一定义为：z：金融指数；y：市场指数；：变量的标准差；：变量的方差；：变量的期望值；：代表求变量的最小值。其它的符号请参见上面式子的定义。） 其中VaR最为流行。金融衍生产品是一大金融创新，同时也给金融市场带来了前所未有的巨大冲击，风险的度量需要一种广泛接受的尺度。在这种背景下，VaR诞生了。如今，VaR模型已经成为国际金融领域进行金融风险管理的主流方法。与传统的风险度量方法不同，VaR模型提供了对于投资组合整体风险的很好的度量。不同的金融产品有专门的风险度量方法，例如，对于股票组合的风险度量，通常可采用BETA系数，TrackingError等指标；对于普通债券的风险度量，通常可采用久期（Duration）和凸性（Convexity）等指标；对于可转换债券的风险度量，还需考虑其可转换的期权特征[5]。但是，人们更关心由各种类别混合组成的金融资产的整体风险，此时，以上所说的几种指标就无能为力了。VaR模型可以通过考虑各类组成资产的配置比例、各自的特点和相互之间的关系，从而计算出投资组合整体的整体风险。VaR的另一个重要的特征还在于它的透明性，仅此一个VaR数值所表述的潜在风险可使任何人都能弄明白风险的程度。VaR模型本质上是使用标准的统计分析技术来评估风险。更确切地说，VaR模型衡量的是在一般的市场情况和给定的置信水平下，金融资产在一个给定的时间区间可能面临的最大损失。 但是，VaR作为广泛应用的风险度量方法，本身固有的缺陷也遭到了的批评。其中最为突出的是VaR只反映风险发生的概率，而不能反映超过它的“尾部风险”。为了弥补这个不足，Albrecht 建议用不足量（Shortfall）来度量“尾部风险”，而Artzner用“尾部条件期望”
XXX市数据中心可行性研究报告
目录 1概述 (6) 1.1项目背景 (6) 1.2项目意义 (6) 2建设目标与任务 (6) 3需求分析 (8) 3.1用户需求 (8) 3.2数据需求 (9) 3.2.1数据资源现状 (9) 3.3系统及应用需求分析 (12) 3.3.1节点管理 (14) 3.3.2主题管理 (14) 3.3.3元数据管理 (14) 3.3.4公共代码管理 (15) 3.3.5数据采集 (15) 3.3.6数据整理比对 (15) 3.3.7数据交换 (15) 3.3.8数据访问 (16)
3.3.10标准管理 (16) 3.3.11应用支持 (16) 3.3.12运行管理 (16) 3.4性能需求分析 (17) 3.4.1业务处理量分析 (17) 3.5安全保障体系需求分析 (20) 3.5.1系统安全可靠性需求 (20) 3.5.2数据安全保密性需求 (20) 3.5.3数据完整性需求 (20) 3.5.4实体的可鉴别性需求 (20) 3.5.5不可否认性需求 (21) 3.5.6对象和行为的可授权性需求 (21) 3.5.7统一信任与授权策略需求 (21) 3.5.8数据中心统一安全监管性需求 (21) 3.6保障机制需求分析 (22) 4数据中心设计方案 (22) 4.1设计原则 (22) 4.1.1统一建设 (22) 4.1.2相对独立 (23) 4.1.3共建共享 (23) 4.1.4安全可靠 (23)
4.2.1平台总体架构 (23) 4.2.2信息资源 (25) 4.2.3支撑平台 (30) 4.2.4数据共享交换平台 (37) 4.2.5共享数据管理系统 (42) 4.2.6保障机制 (45) 4.2.7标准法规体系 (47) 4.2.8安全保障体系 (47) 4.2.9数据接口系统 (51) 4.2.10运行环境 (52) 4.3数据中心成效应用 (57) 4.3.1综合治税专题共享应用系统 (58) 4.3.2企业基础信息共享系统功能 (61) 4.3.3社会保障信息共享应用 (61) 4.4工程建设分期及规模 (62) 5数据中心预算经费 (62) 5.1总投资概算 (62) 5.2投资概算明细 (64) 6风险分析和控制 (68) 7经济及社会效益 (70)
大数据中心项目 可行性研究报告新修版 中咨国联出品
目录 第一章总论 (9) 1.1项目概要 (9) 1.1.1项目名称 (9) 1.1.2项目建设单位 (9) 1.1.3项目建设性质 (9) 1.1.4项目建设地点 (9) 1.1.5项目负责人 (9) 1.1.6项目投资规模 (10) 1.1.7项目建设规模 (10) 1.1.8项目资金来源 (12) 1.1.9项目建设期限 (12) 1.2项目建设单位介绍 (12) 1.3编制依据 (12) 1.4编制原则 (13) 1.5研究范围 (14) 1.6主要经济技术指标 (14) 1.7综合评价 (16) 第二章项目背景及必要性可行性分析 (17) 2.1项目提出背景 (17) 2.2本次建设项目发起缘由 (19) 2.3项目建设必要性分析 (19) 2.3.1促进我国大数据中心产业快速发展的需要 (20) 2.3.2加快当地高新技术产业发展的重要举措 (20) 2.3.3满足我国的工业发展需求的需要 (21) 2.3.4符合现行产业政策及清洁生产要求 (21) 2.3.5提升企业竞争力水平，有助于企业长远战略发展的需要 (21) 2.3.6增加就业带动相关产业链发展的需要 (22) 2.3.7促进项目建设地经济发展进程的的需要 (22) 2.4项目可行性分析 (23) 2.4.1政策可行性 (23) 2.4.2市场可行性 (23) 2.4.3技术可行性 (23) 2.4.4管理可行性 (24) 2.4.5财务可行性 (24) 2.5大数据中心项目发展概况 (24) 2.5.1已进行的调查研究项目及其成果 (25) 2.5.2试验试制工作情况 (25) 2.5.3厂址初勘和初步测量工作情况 (25)
数据中心建设项目可行性研究报告
目录 1概述 (4) 1.1项目背景 (4) 1.2项目意义 (4) 2建设目标与任务 (4) 3需求分析 (6) 3.1用户需求 (6) 3.2数据需求 (6) 3.2.1数据资源现状 (6) 3.3系统及应用需求分析 (10) 3.3.1节点管理 (12) 3.3.2主题管理 (12) 3.3.3元数据管理 (12) 3.3.4公共代码管理 (12) 3.3.5数据采集 (13) 3.3.6数据整理比对 (13) 3.3.7数据交换 (13) 3.3.8数据访问 (13) 3.3.9数据备份与恢复 (13) 3.3.10标准管理 (13) 3.3.11应用支持 (14) 3.3.12运行管理 (14) 3.4性能需求分析 (14) 3.4.1业务处理量分析 (14) 3.5安全保障体系需求分析 (16) 3.5.1系统安全可靠性需求 (16) 3.5.2数据安全保密性需求 (17) 3.5.3数据完整性需求 (17) 3.5.4实体的可鉴别性需求 (17) 3.5.5不可否认性需求 (17) 3.5.6对象和行为的可授权性需求 (17) 3.5.7统一信任与授权策略需求 (18) 3.5.8数据中心统一安全监管性需求 (18) 3.6保障机制需求分析 (18) 4数据中心设计方案 (19) 4.1设计原则 (19) 4.1.1统一建设 (19) 4.1.2相对独立 (19) 4.1.3共建共享 (19) 4.1.4安全可靠 (19) 4.2数据中心平台设计 (20) 4.2.1平台总体架构 (20)
4.2.2信息资源 (21) 4.2.3支撑平台 (25) 4.2.4数据共享交换平台 (30) 4.2.5共享数据管理系统 (35) 4.2.6保障机制 (37) 4.2.7标准法规体系 (39) 4.2.8安全保障体系 (39) 4.2.9数据接口系统 (41) 4.2.10运行环境 (42) 4.3数据中心成效应用 (45) 4.3.1综合治税专题共享应用系统 (45) 4.3.2企业基础信息共享系统功能 (48) 4.3.3社会保障信息共享应用 (48) 4.4工程建设分期及规模 (49) 5数据中心预算经费 (49) 5.1总投资概算 (49) 5.2投资概算明细 (50) 6风险分析和控制 (52) 7经济及社会效益 (54)
平稳性检验与协整检验操作步骤 在对时间序列Y、X1进行回归分析时需要考虑Y与X1之间是否存在某种切实的关系，所以需要进行协整检验。 1.1 利用eviews创建时间序列Y、X1 : 点击file-new-workfile，见对话框又三块空白处 workfile structure 打开eviews软件 type处又三项选择，分别是非时间序列unstructured/undate，时间序列dated-regular frequency，和不明英语balance panel。选择时间序列dated-regular frequency。在date specification中选择年度，半年度或者季度等，和起始时间。右下角为工作间取名字和页数。点击ok。 在所创建的workfile中点击object-new object，选择series，以及填写名字如Y，点击OK。将数据填写入内。 1.2 对序列Y进行平稳性检验: 此时应对序列数据取对数，取对数的好处在于可将间距很大的数据转换为间距较小的数据。具体做法是在workfile y的窗口中点击Genr，输入logy=log(y),则生成y的对数序列logy。再对logy序列进行平稳性检验。 点击view-United root test，test type选择ADF检验，滞后阶数中lag length选择SIC检验，点击ok得结果如下: Null Hypothesis: LOGY has a unit root Exogenous: Constant Lag Length: 0 (Automatic based on SIC, MAXLAG=1) t-Statistic Prob.* Augmented Dickey-Fuller test
可行性研究报告大数据 篇一：大数据可行性研究报告 大数据项目可行性研究报告 XX年 前言 可行性研究报告是从事一种经济活动（投资）之前，双方要从经济、技术、生产、供销直到社会各种环境、法律等各种因素进行具体调查、研究、分析，确定有利和不利的因素、项目是否可行，估计成功率大小、经济效益和社会效果程度，为决策者和主管机关审批的上报文件。 中商产业研究院每年完成项目数量达数百个，在养老产业、商业地产、产业地产、产业园区、互联网、电子商务、民营银行、民营医院、农业、养殖业、生态旅游、酒店、机械电子等行业积累了丰富的项目案例，可对同行业项目提供具有参考性、建设性意见，为客户设计该项目的建设方案，完成包括市场和销售、规模和产品、厂址及建设工程方案、原辅料供应、工艺技术、设备选择、人员组织、实施计划、投资与成本、效益及风险等的计算和评价；内容详实、严密地论证项目的可行性和投资的必要性。我们策划编制的大数据X项目可行性研究报告在发改委、投资商与金融机构的审慎下处于同行领先水平。
【出版日期】 XX年 【交付方式】 Email电子版/特快专递【价格】订制 大数据项目可行性研究报告 第一章项目总论 一、项目背景 二、项目简介 三、项目可行性与必要性分析 四、主要经济指标说明 五、可行性研究报告编制依据 第二章项目建设单位介绍 一、项目建设单位介绍 二、经营业绩 三、资质证书 第三章大数据市场分析 一、大数据行业发展现状 二、大数据行业市场规模分析与预测
三、大数据市场分析小结 第四章项目总体规划 一、项目定位 二、项目功能 三、主要服务内容 第五章运营管理 一、商业模式 二、运营模式 第六章项目建设条件 一、项目选址 二、地理位置 三、交通条件 四、基础设施 第七章工程建设方案与总图布置 一、工程建设基本原则 二、总图布置方案 三、建设经济指标
金融风险测度方法及其应用研究 【摘要】：近年来，随着经济全球化和资本自由化趋势的不断加深，金融创新的不断推进，金融市场规模和效率明显提高的同时，金融市场的波动性在不断增强，风险也在不断积聚，严重时直接导致金融机构倒闭，甚至导致整个国家乃至全球的金融危机。如2007年的这场始于美国次贷危机其后席卷全球的金融危机。故对于金融机构和投资者而言，风险管理和经济资本管理已尤为重要，是在金融市场中稳定发展的法宝，而风险管理和经济资本管理的核心就是金融风险的计量。本文主要对现有的金融风险测度方法进行了理论和实证研究。在理论研究部分，介绍了现有的金融风险测度的3个公理化标准(一致性风险度量、凸性风险度量、动态风险度量)和6个金融风险测度，历史悠久的VaR测度、CVaR测度、ES测度、熵测度、剩余熵测度、谱风险测度，并详细地阐述了各个金融风险测度的计算方法，客观评价了这几个金融风险测度的优缺点。在此基础上对银行持有股票的风险和自身股票价值进行实证研究。实证研究部分主要由两方面构成。第一方面，由于目前的金融机构已不单单地需要进行金融风险计量，而需要对这些风险计提经济资本，所以本文实证研究的角度是如何进行经济资本计量。第二方面，由于巴塞尔协议Ⅲ重申了普通股的重要性，故本文在实证中对银行自由普通股的风险进行了计量，以明确普通股的价值。文章首先对收益率序列的统计特征和分布进行实证分析，以便明确收益率序列的分布，然后基于不同金融风险测度运用适
当的方法对收益率序列进行了风险和经济资本计量，并对结果进行比较研究。研究表明，虽然CVaR测度比V aR测度可以更好地度量尾部风险，但对于各个损失的权重相同，与实际不符，而谱风险测度对于不同的损失赋予不同的权重，并考虑了投资者的风险厌恶程度，在现在的金融市场中，是一个更为合适的风险测度方法。熵风险测度只考虑了金融风险的不确定性，而没有考虑损失的程度，相对而言，在实际金融市场当中的适用性较小，但其为衡量不确定提供了更好的角度，优于方差。【关键词】：金融风险风险测度公理化标准经济资本计量 【学位授予单位】：山西财经大学 【学位级别】：硕士 【学位授予年份】：2013 【分类号】：F830.3;F224 【目录】：摘要6-8Abstract8-121导论12-191.1选题背景及其意义12-131.2国内外研究现状13-161.3研究内容与研究方法16-171.4主要工作与创新171.4.1主要工作171.4.2创新之处171.5论文结构17-192金融风险概述19-242.1风险19-202.2金融风险概念及其分类20-222.3金融风险管理22-232.4小结23-243金融风险度量的公理化标准24-283.1基本性质24-253.2一致性风险度量253.3凸性风险度量25-263.4动态风险度量26-273.5小结27-284金融风险测度理论与方法28-434.1VaR族测度28-314.1.1VaR测度(Valueatrisk)28-314.1.2CVaR测度(ConditionValueatRisk)314.2失真风
金融风险度量方法选择及适用性分析 在很长时期内风险价值模型（Value at Risk，以下简称VaR）都作为首选来度量风险，然而其理论和应用都存在缺陷。VaR并没有考虑潜在的尾部风险，而且不满足一致性风险度量的公理条件，即VaR不是一个理想的风险度量。本文从理论上分析了VaR模型存在的缺陷，并介绍其他风险度量模型，研究其特性，最后在此基础上提出金融风险度量选择的依据。 关键词：风险价值一致性风险度量期望短缺谱风险度量扭曲风险度量 回顾金融风险管理理论的发展史，20世纪70年代是现代金融风险管理发展的重要年代。布雷顿森林体系破产之后，利率、汇率等市场风险问题在金融机构的风险管理中日益凸显。而1973年4月，芝加哥期权交易所（CBOE）的正式运营以及著名的布莱克-舒尔茨期权定价模型的发表标志着现代金融风险管理时代的到来。20世纪90年代，以金融工程为代表的现代金融风险管理技术发展迅速，市场风险和信用风险的量化管理也得到了很大的发展。然而长期资本管理公司（LTCM）的破产为金融工程的应用提出了警示。金融工程的发展使得大量的数理统计模型在金融风险管理中获得应用，这其中包括著名的VaR模型。 我国金融市场是一个发展中的新兴市场，金融风险管理的手段还比较落后，主要以定性分析为主，重在事后分析和评估，缺少事前风险防范和控制。随着我国的金融改革的发展和金融市场的进一步开放，金融监管的原则与风险管理的技术必须符合国际惯例要求。 VaR模型的产生及其局限性 风险管理的基础和核心是对风险的定量分析和评估，即风险度量。传统的风险度量方法如Beta、Delta、久期和凸性等仅适用于特定的金融工具或领域，难以全面反映风险覆盖情况。在这一背景下，1993年G30小组首先提出风险价值（Value at Risk）的概念，VaR模型旨在估计给定投资工具或组合在未来资产价格波动下可能的潜在损失。这一指标最大的优点是能够测量由不同市场因子导致的风险，以及不同市场的总风险，能够较为准确地测量不同风险因子及其相互作用而产生的损失，能够适应金融市场发展的动态性、复杂性和全球化的趋势。 然而，VaR度量的是正常市场情况下的市场风险，在现实中，金融市场出现剧烈波动的极端市场情形大量存在，即VaR并没有考虑潜在的极端市场情形。对VaR实践的评估以及对风险度量的进一步研究指出VaR并非一个一致性风险度量，其不满足次可加性的公理条件，从而无法进行风险分散。 正是由于VaR还存在着理论与应用上的缺陷，推动了风险度量的进一步发展。在VaR的基础上许多研究者提出了风险度量的其他方法。Acerbi and Tasche （2002）提出期望尾部损失ES（Expected Shortfall，以下简称ES），Wang（1996）提出扭曲风险度量的概念，Acerbi（2002，2004）将经济学的风险偏好理论引入风险度量中，提出了谱风险度量，从而使风险管理的实践者有了更多的选择。 基于分位数回归的风险度量 （一）风险价值VaR VaR的含义是“风险中的价值”，JP Morgan将VaR看作既定头寸冲消或重估前可能发生的市场价值的最大损失的估计值。而VaR比较权威的定义由Jorion （1997）提出，将其定义为给定置信水平下，风险资产在持有期内可能遭受的最
概念结构理论 刘壮虎 北京大学哲学系，liuzhh@https://www.doczj.com/doc/0114922549.html, 摘要 本文不从概念的外延和内涵出发，而是将概念作为初始出发点，按照概念结构整体论的观点，在思想—概念—语言三者统一的基础上，建立概念结构的形式理论，讨论其基本性质及其意义，并在此基础上研究若干相关的问题。 实际中使用的推理，比我们通常说的逻辑推理要更广泛，本文建立依赖于语言的相对于主体的推理，并根据这种相对的推理建立相对的一致的概念。通过这种一致的概念，讨论不一致信念集的特征。这种推理也可以部分地用于概念的分类上，本文通过两个简单的实例来说明这种方法的应用。 词项的同义是语言学中的重要问题，按整体论的观点，比同义更一般的不可分辨性更为重要，本文给出了概念的不可分辨性的定义，并讨论其在语言中的表现。不同语言间的翻译也是语言学中的重要问题，本文在概念结构的形式理论基础上的对不同语言间的翻译进行了一些初步的讨论。 本文只是在对最简单的语言进行讨论，通过这样的讨论体现概念结构形式理论的思想、方法和研究框架。 §1前言 一、外延和内涵 概念有外延和内涵，是概念研究中的一个教条。我认为，这个教条是错误的，至少是不准确的。 概念有不同类型的，如亚里士多德就提出了十大范畴，而在三段论中使用的只是实体范畴和性质范畴。在讨论概念的外延和内涵时，也往往集中在个体、类和性质的范围内（与实体范畴和性质范畴相当），就算有所推广，也不是所有的概念。就是在个体、类和性质的范围内，概念有外延和内涵也是存在质疑的，如不可数名词的外延、性质化归为类等问题。 对外延和内涵的形式化的研究中，大多数说的是语句的外延和内涵，如各种内涵逻辑，它们与概念的外延和内涵是完全不同。 将内涵看作可能世界到外延的函数（或者在此基础上的修改），对于处理语句的内涵确实是一种比较好的方法，但将这种方法用于处理概念的内涵和外延，却带
深圳xx科技股份有限公司 xx科技东莞大数据及云计算数据中心产业园项目可行性研究报告
目录第一章总论1 1.1项目概要1 1.1.1项目名称1 1.1.2项目建设单位1 1.1.3项目建设性质1 1.1.4项目建设地点1 1.1.5项目负责人1 1.1.6项目投资规模1 1.1.7项目建设规模2 1.1.8项目资金来源2 1.1.9项目建设期限3 1.2项目企业基本情况3 1.3编制依据3 1.4编制原则4 1.5研究范围5 1.6主要经济技术指标5 1.7综合评价6 第二章项目背景及必要性分析7 2.1项目提出背景7 2.2项目发起缘由8 2.3项目建设必要性分析8 2.3.1加快当地高新技术产业发展的的重要举措8
2.3.2顺应广东大数据产业快速发展的需要9 2.3.3推动东莞“智慧城市”工程建设快速发展的需要9 2.3.4提升企业竞争力水平有利于项目企业做大做强的需要10 2.3.5增加就业带动相关产业链发展的需要11 2.3.6促进项目建设地经济发展进程的的需要11 2.4项目可行性分析11 2.4.1政策可行性11 2.4.2实施条件可行性18 2.4.3技术及业务拓展优势可行性19 2.4.4管理可行性19 2.5分析结论19 第三章行业市场分析21 3.1我国大数据产业市场统计分析21 3.2我国大数据产业发展前景分析分析24 3.3我国云数据中心行业发展统计分析24 3.4广东省云计算大数据产业状况及前景分析27 3.4东莞市云计算大数据产业发展前景分析28 3.5市场分析结论31 第四章项目建设条件33 4.1地理位置选择33 4.2区域投资环境33 4.2.1区域地理位置33 4.2.2区域地形地貌条件34 4.2.3区域自然气候条件34 4.2.4区域交通运输条件35
1 绪论 1.1 引言 现代金融理论的核心是研究在不确定条件下投资者以及市场如何对金融、货币及其他资产进行有效配置，从而获得最大的满足。金融分析方法的发展使金融理论内容逐渐形成了三个主要方面，正如学者兹维·博迪所总结的——现代金融分析的三大支柱分别是：跨时期最优化，主要研究投资者生命期资产配置、消费选择等；资产估值，涉及的有资本资产定价、衍生品定价、估值折现模型等；风险管理与组合选择，包括风险测度理论、投资组合选择模型等[28]。而本文研究主题就是三大支柱之一——金融风险管理和投资组合选择。 现代投资组合理论被认为是整个现代金融学的发端。该理论发端于1952年Markwitz在《Journal of Finance》上发表的一篇论述理性投资者为获得最大效用从而如何分配其资产的论文，其使用均值方差模型代表理性投资者共同的选择模型，从而得到了最佳的资产配置方案，第一次将风险资产的期望收益与代表风险的方差结合起来研究资产组合选择问题，从而为现代投资组合理论(modem portfolio theory，MPT)的发展奠定了基础[13]。其实分散化在经济和金融学届早有讨论，但都属于感性认知阶段，Markwitz这一理论的问世，使金融学开始摆脱了纯粹描述性的研究和单凭经验操作的状态，数量化方法开始进入金融领域，“鸡蛋不能同时放在一个篮子里”这句投资领域的俗语被众多学者通过不同的数学模型展示和理论上证明出来。但是不同模型所求得的最优组合解也存在差异，因而如何选择适合的风险度量工具作为约束条件，并高效地求解投资模型成为现代投资理论中极其重要的两个课题。 一方面，当深入考量市场参与者偏好、市场结构等因素时学者们发现以方差代表风险大小并不恰切[1]，因而风险度量理论随之兴起，其引发的就是半方差、平均绝对离差（MAD）、VAR、CVAR等度量工具以及一致风险测度、凸风险测度、谱风险测度等测度理论的相继出现。 另一方面，现实金融环境下小样本问题、资产历史收益数据波动问题（噪声）等对投资组合规划求解也构成了挑战。为此，部分学者结合计算数学与投资理论，在适当修正投资模型的基础上将遗传算法、蚁群算法等引入投资规划问题的计算；而另一部分学者则试图从理论上探讨特定风险度量工具约束下投资组合模型
2019年基于大数据和人工智能的视频云平台项目可行性研究报告
目录 一、大数据和人工智能的视频云平台项目概况 (3) 二、项目实施的必要性 (3) （1）行业发展与新技术融合的现实需求 (3) （2）顺应市场发展趋势，增强企业竞争力的需要 (4) ①提升资源使用效率 (4) ②为数据的融通提供可能 (5) ③解决海量视频图像信息大数据和人工智能处理的算力问题 (5) ④开放的云模式构建繁荣生态 (5) ⑤更为强大的智能化功能 (6) 三、项目实施对企业未来盈利能力的影响 (6) 四、项目实施对偿债能力和资本结构的影响 (6) 五、项目投资概算 (6) 六、项目建设期及实施进度 (7)
一、大数据和人工智能的视频云平台项目概况 企业计划在现有智能视频产品研发中心基础上组建基于大数据和人工智能的视频云平台开发团队，开发新一代视频云平台产品，提供对结构化、非结构化数据的统一存储、查询、分析和二次加工能力。 新一代视频云平台将利用云计算、大数据、智能视频等新技术升级改造现有视频图像监控系统，有效解决视频图像数据采集整合、价值信息提取、数据结构化处理及存储应用模式变革等问题，建设云架构下视频信息应用平台，为安防实战应用提供服务支撑。通过本项目的开发，企业将进一步提升服务于平安城市、雪亮工程和智慧城市项目的能力，满足市场发展需求，新一代视频云平台的具体建设内容包括：视频云基础设施平台、SVAC视音频数据解析平台、SVAC结构化大数据平台以及丰富多样的业务应用系统。 二、项目实施的必要性 新一代视频云平台产品有助于进一步提升中星技术的技术领先地位，保持企业在行业中的竞争力。 同时可以为政府、公安用户实现从网络监控向智能监控的迁移，扩大企业在平安城市、雪亮工程和智慧城市的市场份额，带动企业收入和利润的不断增长。 （1）行业发展与新技术融合的现实需求 云计算、物联网、大数据以及人工智能等创新技术的不断发展，推动着安防行业与IT技术愈发紧密的融合，云安防时代即将到来。
深圳xx科技股份有限公司xx科技东莞大数据及云计算数据中心产业园项目 可行性研究报告
目录 第一章总论1 1.1项目概要1 1.1.1项目名称1 1.1.2项目建设单位1 1.1.3项目建设性质1 1.1.4项目建设地点1 1.1.5项目负责人1 1.1.6项目投资规模1 1.1.7项目建设规模2 1.1.8项目资金来源2 1.1.9项目建设期限3 1.2项目企业基本情况3 1.3编制依据3 1.4编制原则4 1.5研究范围5 1.6主要经济技术指标5 1.7综合评价6 第二章项目背景及必要性分析7 2.1项目提出背景7 2.2项目发起缘由8 2.3项目建设必要性分析8 2.3.1加快当地高新技术产业发展的的重要举措8 2.3.2顺应广东大数据产业快速发展的需要9 2.3.3推动东莞“智慧城市”工程建设快速发展的需要9 2.3.4提升企业竞争力水平有利于项目企业做大做强的需要10 2.3.5增加就业带动相关产业链发展的需要11 2.3.6促进项目建设地经济发展进程的的需要11 2.4项目可行性分析11 2.4.1政策可行性11 2.4.2实施条件可行性18 2.4.3技术及业务拓展优势可行性19 2.4.4管理可行性19 2.5分析结论19 第三章行业市场分析21 3.1我国大数据产业市场统计分析21 3.2我国大数据产业发展前景分析分析24
3.3我国云数据中心行业发展统计分析24 3.4广东省云计算大数据产业状况及前景分析27 3.4东莞市云计算大数据产业发展前景分析28 3.5市场分析结论31 第四章项目建设条件33 4.1地理位置选择33 4.2区域投资环境33 4.2.1区域地理位置33 4.2.2区域地形地貌条件34 4.2.3区域自然气候条件34 4.2.4区域交通运输条件35 4.2.5区域经济发展条件36 第五章总体建设方案38 5.1规划设计原则38 5.2整体规划方案38 5.3数据中心部分规划38 5.4产业园商业模式39 5.5项目总平面布置原则39 5.6规划总体布局39 5.7土建工程方案41 5.7.1方案指导原则41 5.7.2主要建筑工程41 5.8工程管线布置方案41 5.8.1给排水41 5.8.2供电43 5.9土地利用情况44 5.9.1项目用地规划选址44 5.9.2用地规模及用地类型44 第六章节约能源方案45 6.1用能标准和节能规范45 6.2项目能源消耗情况45 6.3项目区能源供应情况46 6.4项目节能措施46 第七章环境保护与消防措施48 7.1设计依据及原则48 7.1.1环境保护设计依据48 7.1.2设计原则48 7.2建设地环境条件48
中北大学 数据库课程设计 概念结构和逻辑结构设计 2012 年 6月 3 日
一、概念结构设计 建立系统数据模型的主要工具是实体-联系图，即E-R图。E-R图的图形符号约定如表1-1所示： 表 1-1 E—R图的图形符号 系统的E-R图，如图1-1所示，每个实体及属性如下： 家庭成员：姓名、称呼、密码、出生日期 收入记录：收入项目编号、收入项目名称、收入人员、收入金额、收入日期 支出记录：支出项目编号、支出项目名称、支出人员、支出金额、支出日期 银行信息：银行账号、银行名称、开户人、存款金额、开户日期 1.家庭成员关系E-R图 2.收入记录E-R图
3.支出记录E-R图 4.银行信息E-R图 5.系统E-R图
二、逻辑结构设计 1.概述 数据库逻辑设计将概念结构转换为某个DBMS所支持的数据模型对其进行优化。 在对该家庭理财管理系统的实体关系图进行了分析之后，分别对其实体、联系作了属性的分析，得出这些实体与联系的主键与码值，为以后对该家庭理财管理系统的数据库的物理设计提供了方便与基础。 2.数据模型 2.1基本的数据模型有: 家庭成员（姓名、称呼、密码、出生日期）； 收入记录（收入项目编号、收入项目名称、收入人员、收入金额、收入日期）; 支出记录(支出项目编号、支出项目名称、支出人员、支出金额、支出日期); 银行信息(银行账号、银行名称、开户人、存款金额、开户日期) ; 2.2经过优化后的数据模型有： 家庭成员（ID，姓名、称呼、密码、出生日期）； 银行信息（银行账号、银行名称、开户人、存款金额、开户日期）； 使用者（ID，帐号，密码）； 收入记录（ID，名称，收入人员，金额，日期）； 支出记录（ID，名称，支出人员，金额，日期）； 管理收入（家庭成员ID，收入记录ID）； 管理支出（家庭成员ID，支出记录ID）； 查看收入（家庭成员ID，收入记录ID）； 查看支出（家庭成员ID，支出记录ID）；
云计算数据中心可行性研究报告 二o—年十月
目录 第1章、总论 (1) 1.1 概述 (1) 1.2 建设背景 (1) 1.3 建设必要性和可行性 (2) 1.4 建设目标与任务 (2) 第2章、需求分析 (4) 2.1 用户需求 (4) 2.2 数据需求 (4) 2.3 系统及应用需求分析 (7) 2.3.1 节点管理 (8) 2.3.2 主题管理 (8) 2.3.3 元数据管理 (8) 2.3.4 公共代码管理 (9) 2.3.5 数据采集 (9) 2.3.6 数据整理比对 (9) 2.3.7 数据交换 (9) 2.3.8 数据访问 (10) 2.3.9 数据备份与恢复 (10) 2.3.10 标准管理 (10) 2.3.11 应用支持 (10) 2.3.12 运行管理 (10) 2.4 性能需求分析 (11) 2.4.1 业务处理量分析 (11) 2.5 安全及保障机制需求分析 (12) 2.5.1 系统安全可靠性需求 (12) 2.5.2 数据安全保密性需求 (12) 2.5.3 数据完整性需求 (13) 2.5.4 实体的可鉴别性需求 (13) 2.5.5 不可否认性需求 (13) 2.5.6 对象和行为的可授权性需求. (13)
2.5.7 统一信任与授权策略需求 (13) 2.5.8 数据中心统一安全监管性需求 (14) 2.5.9 保障机制需求分析 (14) 第3章、数据中心设计方案 (15) 3.1 设计原则 (15) 3.1.1 统一建设 (15) 3.1.2 相对独立 (15) 3.1.3 共建共享 (15) 3.1.4 安全可靠 (15) 3.2 数据中心平台设计 (16) 3.2.1 平台总体架构 (16) 3.2.2 数据资源规划 (16) 3.2.2.1 数据资源规划的总体思路............................. 1. 6 3.2.2.2 数据资源体系结构................................... 1..7 3.2.2.3 共享数据一致性的保证.............................. 1.8 3.2.2.4 共享数据库的建立过程.............................. 1.9 3.2.3 数据支撑平台 (20) 3.2.3.1 数据共享交换子系统................................ 2.0 3.2.3.2 目录管理服务子系统................................ 2.3 3.2.3.3 共享数据管理子系统................................ 2.3 3.2.3.4 共享业务管理子系统................................ 2.4 3.2.3.5 系统配置管理子系统................................ 2.4 3.2.3.6 系统安全管理子系统................................ 2.4 3.2.4 数据共享交换平台 (25) 3.2. 4.1 交换网络结构....................................... 2..5 3.2. 4.2 交换概念模型....................................... 2..7 3.2. 4.3 交换体系结构....................................... 2..8 3.2.5 共享数据管理系统 (30) 3.2.5.1 功能设计........................................... 3..0 3.2.5.2 逻辑结构........................................... 3..2 3.2.6 数据接口系统 (32)