ORACLE SQL總結三：DDL語句

五、DDL語句
5.1 Enable/Disable/Validate/Novalidate 組合特性說明： 

是否要求知足約束 Validate                 Novalidate
              已有記錄    新增/修改記錄      已有記錄       新增/修改記錄
Enable   Yes          Yes                       No                Yes
Disable  Yes          No                        No                No

Validate確保已有數據符合約束；
Novalidate沒必要考慮已有數據是否符合約束。

除非Novalidate被指定，Enable默認Validate；
除非Validate被指定，Disable默認Novalidate；
Validate和Novalidate對Enable和Disable沒有任何默認暗示。

Enable Validate與Enable相同，檢查已有記錄和新增記錄，確保都符合約束；
Enable Novalidate 容許已有記錄沒必要知足約束條件，但新增/修改的記錄必須知足；
Disable Validate禁用約束，刪除約束上的索引，不容許修改任何被約束的記錄；
Disable Novalidate與Disable相同，禁用約束，刪除約束上的索引，且容許修改被約束的記錄。

詳細參考sql references <constraint>

5.2 關於partition表的疑問
Partitioning allows a table, index, or index-organized table to be subdivided into smaller pieces, where each piece of such a database object is called a partition. Each partition has its own name, and may optionally have its own storage characteristics.
partitioning容許表、索引、或索引組織表切分紅更小的片，每片稱爲partition,每一個partition有本身的name,並能夠有本身的存儲特性。

oracle手冊上也說partition的優勢是能夠並行訪問分區（由於每一個分區表能夠放在不一樣的硬盤上），這樣能夠提高性能。

那麼個人問題來了，若是我只有一塊硬盤，那麼全部的partition 表就只能放在這一塊硬盤上，是否是即便作了partition表也不能提高性能呢？

5.3 索引和索引-組織表

索引的類型：
(1)B-TREE索引，又分爲:
            索引-組織表
            反序鍵索引
            倒序索引
            B-TREE集羣索引
(2)Bitmap 索引
(3)Function-based 索引
(4)應用域索引

《oracle concept》關於索引描述得很詳細，翻譯部份內容
**************
An index is an optional structure, associated with a table or table cluster, that can sometimes speed data access. By creating an index on one or more columns of a table, you gain the ability in some cases to retrieve a small set of randomly distributed rows from the table. Indexes are one of many means of reducing disk I/O.

一個索引是一個可選的於表和表簇有關係的數據結構，它有時能夠加快數據訪問速度。經過在一個或多個列上產生一個索引，你能夠提高訪問以隨機方式存儲的數據的能力，索引是多種減小硬盤I/O操做的方式之一。

If a heap-organized table has no indexes, then the database must perform a full table scan to find a value. For example, without an index, a query of location 2700 in the hr.departments table requires the database to search every row in every table block for this value. This approach does not scale well as data volumes increase.

若是一個heap-organized table(oracle create table 時默認這種方式)，數據庫必須執行全表掃描來查找一個數據。例如，若是沒有索引，在hr.departments表中查詢location=2700，就必須搜索表中每一個塊(block),這種方式隨着數據的增長性能更加糟糕。

For an analogy, suppose an HR manager has a shelf of cardboard boxes. Folders containing employee information are inserted randomly in the boxes. The folder for employee Whalen (ID 200) is 10 folders up from the bottom of box 1, whereas the folder for King (ID 100) is at the bottom of box 3. To locate a folder, the manager looks at every folder in box 1 from bottom to top, and then moves from box to box until the folder is found. To speed access, the manager could create an index that sequentially lists every employee ID with its folder location:

ID 100: Box 3, position 1 (bottom)
ID 101: Box 7, position 8
ID 200: Box 1, position 10
.

假設一種情形，一個HR經理有一個裝滿卡片箱子的書架，收藏着僱員信息的文件夾被隨機地放在盒子裏，每一個盒子裏有10個文件夾，僱員Whalen(ID 200)的文件夾被放在第1個盒子的頂部，僱員King(ID 100)的文件夾被放在第1個盒子的底部，HR經理必須從頂到底地查詢每一個盒子裏的文件夾，而且逐個逐個地查詢盒子，直到找到所需的文件夾。爲了加快查詢速度，經理能夠作一張表，表上順序第列出每一個僱員ID和他的文件夾所放的位置。

Bitmap Indexes

位圖索引

In a bitmap index, the database stores a bitmap for each index key. In a conventional B-tree index, one index entry points to a single row. In a bitmap index, each index key stores pointers to multiple rows.

在位圖索引中，數據庫爲每一個index key都存儲了一個位圖(bitmap)。在通常的B-tree索引中，一個索引實體(entry)指向一條記錄(a single row),可是在位圖索引中，每一個index key指向多條記錄(multiple rows)

Bitmap indexes are primarily designed for data warehousing or environments in which queries reference many columns in an ad hoc fashion. Situations that may call for a bitmap index include:

The indexed columns have low cardinality, that is, the number of distinct values is small compared to the number of table rows.

The indexed table is either read-only or not subject to significant modification by DML statements.

位圖索引主要設計用於數據倉庫或相似的有隨機方式分佈的大量的列的數據環境，可使用位圖索引的情形包括：
-索引列有較低的類似度，這就意味着，在表的記錄中相同值的數據的數量比較少。
-被索引的表或者只讀或者不是DML語句重點照顧的對象

For a data warehouse example, the sh.customer table has a cust_gender column with only two possible values: M and F. Suppose that queries for the number of customers of a particular gender are common. In this case, the customer.cust_gender column would be a candidate for a bitmap index.

舉一個數據倉庫的例子，sh.customer表有一個cust_gender列，這個列裏僅僅包括兩個值：M或F，假設沒有其餘的性別(中性?),在這個例子中 customer.cust_gender列有比較少的類似度，能夠做爲位圖索引。

Each bit in the bitmap corresponds to a possible rowid. If the bit is set, then the row with the corresponding rowid contains the key value. A mapping function converts the bit position to an actual rowid, so the bitmap index provides the same functionality as a B-tree index although it uses a different internal representation.

在位圖中每位(bit)對應一個可能的rowid，若是位被指定，該rowid對應的記錄(row)也就對應了值，一個映射函數將位的位置轉變成一個確切的rowid，這樣位圖索引就以B-TREE索引不一樣方式提供了相同的功能。

If the indexed column in a single row is updated, then the database locks the index key entry (for example, M or F) and not the individual bit mapped to the updated row. Because a key points to many rows, DML on indexed data typically locks all of these rows. For this reason, bitmap indexes are not appropriate for many OLTP applications.

若是被索引的列中有一條記錄被修改，那麼數據庫就會鎖定索引值(好比M或F)，由於一個索引值對應不少記錄，即數據庫不會只鎖定被修改的記錄，連那些與該記錄有相同索引值的記錄也會一塊兒被鎖定。由於這個緣由，位圖索引不適合於OLTP應用。

Index-Organized Tables
索引組織表

An index-organized table is a table stored in a variation of a B-tree index structure. In a heap-organized table, rows are inserted where they fit. In an index-organized table, rows are stored in an index defined on the primary key for the table. Each index entry in the B-tree also stores the non-key column values. Thus, the index is the data, and the data is the index. Applications manipulate index-organized tables just like heap-organized tables, using SQL statements.

索引組織表(index-organized table)是採用B-TREE索引結構存儲方式的表的變種之一，在一個棧組織表(heap-organized table)中，哪裏有多餘的空間，記錄(row)就會被插入到哪裏(也就是說記錄不以順序的方式存儲，物理上是隨機的)。可是在index-organized table中，記錄被存儲在索引中，並按主鍵的順序排列。在B-TREE每一個索引實體也存儲非主鍵的列，所以，索引就是表，表也就是索引。但應用操做index-organized table與操做 heap-organized tables沒有不一樣，也使用SQL語句。

For an analogy of an index-organized table, suppose a human resources manager has a book case of cardboard boxes. Each box is labeled with a number—1, 2, 3, 4, and so on—but the boxes do not sit on the shelves in sequential order. Instead, each box contains a pointer to the shelf location of the next box in the sequence.

Folders containing employee records are stored in each box. The folders are sorted by employee ID. Employee King has ID 100, which is the lowest ID, so his folder is at the bottom of box 1. The folder for employee 101 is on top of 100, 102 is on top of 101, and so on until box 1 is full. The next folder in the sequence is at the bottom of box 2.

In this analogy, ordering folders by employee ID makes it possible to search efficiently for folders without having to maintain a separate index. Suppose a user requests the records for employees 107, 120, and 122. Instead of searching an index in one step and retrieving the folders in a separate step, the manager can search the folders in sequential order and retrieve each folder as found.

Index-organized tables provide faster access to table rows by primary key or a valid prefix of the key. The presence of non-key columns of a row in the leaf block avoids an additional data block I/O. For example, the salary of employee 100 is stored in the index row itself. Also, because rows are stored in primary key order, range access by the primary key or prefix involves minimal block I/Os. Another benefit is the avoidance of the space overhead of a separate primary key index.

Index-organized tables are useful when related pieces of data must be stored together or data must be physically stored in a specific order. This type of table is often used for information retrieval, spatial (see "Overview of Oracle Spatial"), and OLAP applications (see "OLAP").

5.4 CASCADE的做用

<ORACLE SQL REFERENCES>的解釋是：

Specify CASCADE to disable any integrity constraints that depend on the specified integrity constraint. To disable a primary or unique key that is part of a referential integrity constraint, you must specify this clause.

使用CASCADE用於取消（disable）任何依賴於其餘完整性約束的完整性約束，例如，爲了取消（disable）與一個外鍵約束有關係的主鍵約束或惟一性約束，你必須使用CASCADE。

5.6 Restrictions on Check Constraints check約束的限制

Check constraints are subject to the following restrictions:

check約束有以下限制：

• You cannot specify a check constraint for a view. However, you can define the view using the WITH CHECK OPTIONclause, which is equivalent to specifying a check constraint for the view.

  你不能爲一個視圖指定check約束。可是你可使用WITH CHECK OPTION從句定義一個視圖。這等同與你爲視圖指定check 約束。

• The condition of a check constraint can refer to any column in the table, but it cannot refer to columns of other tables.

  check約束能夠指向一個表的任何列，可是它不能指向其餘表的列。

• Conditions of check constraints cannot contain the following constructs:

  check約束的條件不能包括如下內容

  • Subqueries and scalar subquery expressions

    子查詢和scalar subquery？？如何翻譯

  • Calls to the functions that are not deterministic (CURRENT_DATE, CURRENT_TIMESTAMP, DBTIMEZONE,LOCALTIMESTAMP, SESSIONTIMEZONE, SYSDATE, SYSTIMESTAMP, UID, USER, and USERENV)

    不能調用以下函數CURRENT_DATE,CURRENT_TIMESTAMP, DBTIMEZONE,LOCALTIMESTAMP,SESSIONTIMEZONE,SYSDATE,SYSTIMESTAMP,UID,USER,USERENV

  • Calls to user-defined functions

    調用用戶自定義函數

  • Dereferencing of REF columns (for example, using the DEREF function)

    ？？如何翻譯

  • Nested table columns or attributes

    嵌套表的列或屬性

  • The pseudocolumns CURRVAL, NEXTVAL, LEVEL, or ROWNUM

    僞列CURRVAL,NEXTVAL,LEVEL,ROWNUM

  • Date constants that are not fully specified

    沒有徹底指定（仍是定義）的靜態數據