關係型數據庫系統

它通過數據、關係和對數據的約束三者組成的數據模型來存放和管理數據。三十多年來，RDBMS獲得了長足的發展，許多企業的在線交易處理系統、內部財務系統、客户管理系統等大多采用了RDBMS。太字節級關係型數據庫在大型企業集團中已是司空見慣。業界普遍使用的關係型數據庫管理系統產品有IBM DB2通用數據庫、Oracle以及SQL Server等。 　DB2是IBM出口的一系列關係型數據庫管理系統，分別在不同的操作系統平台上服務。雖然DB2產品是基於UNIX的系統和個人計算機操作系統，在基於UNIX系統和微軟在windows系統下的Access方面，DB2追尋了ORACLE的數據庫產品。 　Oracle是關係型數據庫管理系統，它功能強大、性能卓越，在當今大型數據庫管理系統中佔有重要地位。

1.1.1 什麼是關係型

關係型是以關係數學模型來表示的。關係數學模型中以二維表的形式來描述，如表1.1和表1.2所示。

1.1.2 什麼是關係型庫

1. 什麼是主碼（主鍵）

能夠唯一表示表中的每個記錄的【字段】或者【字段】的組合就稱為主碼。

2. 什麼是外碼（外鍵）

表1.2的【編號】字段和表1.1的【導師編號】字段是對應的。表1.2中的【編號】字段是表1.2的主碼。表1.2中的【編號】字段又可以稱為是表1.1的外碼。

1.1.3 什麼是關係型庫系統

一個完整的關係型庫系統包含5層結構，如圖1.1所示。

1. 硬件

硬件指安裝庫系統的計算機，包括兩種。

器

客户機

2. 操作系統

操作系統指安裝庫系統的計算機採用的操作系統。

3. 關係型庫管理系統、庫

關係型庫是存儲在計算機上的、可共享的、有組織的關係型的集合。關係型庫管理系統是位於操作系統和關係型庫應用系統之間的庫管理軟件。

4. 關係型庫應用系統

關係型庫應用系統指為滿足用户需求，採用各種應用開發工具（如VB、PB和Delphi等）和開發開發的庫應用軟件。

5. 用户

用户指與庫系統打交道的人員，包括如下3類人員。

最終用户

庫應用系統開發員

庫管理員

1.1.4 什麼是關係型庫管理系統

1. 定義語言及翻譯程序DDL

2. 操縱語言及編譯（解釋）程序DML

3. 庫管理程序

在以下的表格中，將對一些關係型數據庫管理系統的基本信息和技術信息進行對比。請參考以下產品各自的條目以獲得更詳細的介紹。該表格不可能包羅萬象，也許有些信息已過時。除非註明，以下產品為各自的穩定版本，且沒有安裝任何形式的擴展程序。

維護者 首次發行日期 最新穩定版 軟件授權協議

PostgreSQL PostgreSQL Global Development Group

June 1989 8.2.4 BSD

4th Dimension 4D s.a.s 1984 2004.5 專有

Adaptive Server Enterprise Sybase 1987 15.0 專有

Apache Derby Apache 2004 10.2.2.0 Apache License

DB2 IBM 1982 9 專有

DBISAM Elevate Software

? 4.25 專有

ElevateDB Elevate Software

? 1.01 專有

Firebird Firebird Foundation July 25, 2000 2.0.1 Initial Developer's Public License

Informix IBM 1985 10.0 專有

HSQLDB HSQL Development Group 2001 1.8.0 BSD

H2 H2 Software 2005 1.0 Freeware

Ingres Ingres Corp. 1974 Ingres 2006 II 9.0.4 GPL 與 專有

interbase CodeGear 1985 2007 專有

MaxDB MySQL AB, SAP AG ? 7.6 GPL 或 專有

Microsoft SQL Server Microsoft 1989 9.00.3042 (2005 SP2) 專有

MonetDB The MonetDB Developer Team

2004 4.16 (Feb. 2007) MonetDB Public License v1.1

MySQL MySQL AB 1996年11月 5.0.41 GPL 或 專有

HP NonStop SQL Hewlett-Packard 1987 SQL MX 2.0 專有

Oracle Oracle Corporation 1979年11月 10g Release 2 專有

Oracle Rdb Oracle Corporation 1984 7.2 專有

OpenEdge Progress Software Corporation 1984 10.1B 專有

OpenLink Virtuoso OpenLink Software

1998 4.5.3 (April 2006) GPL 或 專有

Pervasive PSQL Pervasive Software ? 9 專有

Pyrrho DBMS University of paisley 2005年11月 0.5 專有

SmallSQL SmallSQL April 16 2005 0.12 LGPL

SQL Anywhere Sybase 1992 10.0 專有

SQLite D. Richard HiPP August 17 2000 3.3.7 Public domain

Teradata Teradata 1984 V2R8.2 專有

Valentina Paradigma Software Febrary 1998 3.0.1 專有

維護者 首次發行日期 最新穩定版 軟件授權協議

操作系統支持

這些數據庫所能支持的操作系統。

Windows Mac OS X Linux BSD UNIX z/OS 1

PostgreSQL 是 是 是 是 是 否

4th Dimension 是 是 否 否 否 否

Adaptive Server Enterprise 是 是 是 是 是 否

Apache Derby 2

是 是 是 是 是 是

DB2 是 否 是 否 是 是

Firebird 是 是 是 是 是 可能

HSQLDB 2

是 是 是 是 是 是

H2 2

是 是 是 是 是 可能

Informix 是 是 是 是 是 否

Ingres 是 否 是 是 是 可能

InterBase 是 否 是 否 是 (Solaris) 否

Adabas 是 否 是 否 是 是

MaxDB 是 否 是 否 是 可能

Microsoft SQL Server 是 否 否 否 否 否

MonetDB 是 是 是 否 是 否

MySQL 是 是 是 是 是 可能

Oracle 是 是 是 否 是 是

OpenEdge 是 否 是 否 是 否

OpenLink Virtuoso 是 是 是 是 是 是

Pyrrho DBMS 是 (.NET) 否 是 (Mono) 否 否 否

SmallSQL 是 是 是 是 是 是

SQL Anywhere 是 是 是 否 是 否

SQLite 是 是 是 是 是 可能

Teradata 是 否 是 否 是 否

Valentina 是 是 是 否 否 否

Windows Mac OS X Linux BSD UNIX z/OS 1

註記 (1): Open source databases listed as UNIX-compatible will likely compile and run under z/OS's built-in UNIX System Services (USS) subsystem. Most databases listed as Linux-compatible can run alongside z/OS on the same server using Linux on zSeries.

註記 (2): 該項受該平台上Java虛擬機的可用性制約。

基本功能

數據庫系統所能實現的基本功能對比。

ACID 關聯完整性 數據庫事務 Unicode萬國碼

PostgreSQL 是 是 是 是

Adaptive Server Enterprise 是 是 是 是

Apache Derby 是 是 是 是

DB2 是 是 是 是

Firebird 是 是 是 是

HSQLDB 是 是 是 是

H2 是 是 是 是

Informix 是 是 是 是

Ingres 是 是 是 是

InterBase 是 是 是 是

MaxDB 是 是 是 是

Microsoft SQL Server 是 是 是 是

MonetDB 是 是 是 是

MySQL 是 3

是 3

是 3

是

Oracle 是 是 是 是

OpenEdge 是 否 是 是

OpenLink Virtuoso 是 是 是 是

Pyrrho DBMS 是 是 是 是

SQL Anywhere 是 是 是 是

SQLite 是 否 4

Basic 4

是

Teradata 是 是 是 是

Valentina 否 是 否 是

ACID 關聯完整性 數據庫事務 Unicode萬國碼

註記 (3): 需要使用innodb格式數據表才能實現關聯完整性約束與事務。 However, even the InnoDB table type permits storage of values that exceed the data range; some view this as violating the Integrity constraint of ACID.

註記 (4): 外聯鍵約束在語法上有效，但實際上並不能得到強制執行，可使用觸發器替代。不支持嵌套事務。

表與視圖

臨時表 物化視圖(Materialized view)

PostgreSQL 是 否 7

Adaptive Server Enterprise 是 5

否

Apache Derby 是 否

DB2 是 是

Firebird Will be in 2.1 否 (only common views)

HSQLDB 是 否

H2 是 否

Informix 是 是

Ingres 是 Ingres r4

InterBase 是 否

MaxDB 是 否

Microsoft SQL Server 是 是

MonetDB 是 否

MySQL 是 否 6

Oracle 是 是

OpenEdge 是 否

OpenLink Virtuoso 是 是

Pyrrho DBMS 否 否

SQL Anywhere 是 是

SQLite 是 否

Teradata 是 是

Valentina 是 否

臨時表 物化視圖(Materialized view)

註記 (5): 服務器提供臨時數據庫，可供會話存放公共/私有的臨時表。

註記 (6): 物化視圖可用存儲過程和觸發器模擬。

註記 (7): 物化視圖可用PL/PgSQL，PL/Perl，PL/Python或其他過程語言的存儲過程和觸發器模擬。 .

索引

數據庫所支持的索引類型（除基本的B樹外）

R-/R+ tree 哈希 Expression 部分索引(Partial index) 反向索引(Reverse index) 位圖索引（Bitmap） GiST GIN

PostgreSQL 是 是 是 是 是 10

否 11

是 是

Adaptive Server Enterprise 否 否 否 否 是 否 否 否

Apache Derby 否 否 否 否 否 否 否 否

DB2 否 ? 否 否 是 是 否 否

Firebird 否 否 是 否 是 16

否 否 否

HSQLDB 否 否 否 否 否 否 否 否

H2 否 是 否 否 否 否 否 否

Informix 是 是 是 是 是 是 否 否

Ingres 是 是 Ingres r4 否 否 Ingres r4 否 否

InterBase 否 否 否 否 否 否 否 否

MaxDB ? ? 否 否 否 否 否 否

Microsoft SQL Server ? 否n/Cluster & fill factor 是 8

是 9

是 8

否 否 否

MonetDB 否 是 否 否 否 否 否 否

MySQL 僅限MyISAM MEMORY, Cluster (NDB), 僅限InnoDB,17

否 否 否 否 否 否

Oracle EE edition only Cluster Tables 是 是 15

是 是 否 否

OpenLink Virtuoso 是 Cluster 是 否 否 是 否 否

Pyrrho DBMS 否 否 否 否 否 否 否 否

SQL Anywhere 否 否 否 否 否 否 否 否

SQLite 否 否 否 否 是 否 否 否

Teradata 否 是 是 是 否 是 否 否

Valentina 否 否 是 8

是 17

是 是 否 否

R-/R+ tree 哈希 Expression 部分索引(Partial index) 反向索引(Reverse index) 位圖索引（Bitmap） GiST GIN

註記 (8): 可通過索引一個經過計算的列，或使用一個已索引的視圖實現

註記 (9): 可使用索引視圖實現。

註記 (17): InnoDB自動按需生成 adaptive hash index。

註記 (10): 一個有效的PostgreSQL索引可以用來進行倒排序。

註記 (11): PostgreSQL將在8.3中支持保存於磁盤的位圖索引。8.2提供了一種稱為"內存位圖掃描（in-memory bitmap scans）"的相關技術。

註記 (15): 在Oracle 8i及以後的辦本可使用基於函數的索引（Function-based Indexes）實現。

註記 (16): The users need to use a function from freeAdhocUDF library or similar.

註記 (17): 在Valentina中可使用基於函數的索引（Function-based Indexes）實現。

其他對象

有關其他類型對象的支持情況。

數據域 遊標 觸發器 函數 12

存儲過程 12

外部調用 12

PostgreSQL 是 是 是 是 是 是

Adaptive Server Enterprise 是 是 是 是 是 是

Apache Derby 否 是 是 是 13

是 13

是 13

DB2 否 是 是 是 是 是

Firebird 是 是 是 是 是 是

HSQLDB ? 否 是 是 是 是

H2 是 否 是 是 是 是

Informix ? 是 是 是 是 是

Ingres 是 是 是 是 是 是

InterBase 是 是 是 是 是 是

MaxDB 是 是 是 是 是 ?

Microsoft SQL Server 是 (2000 and beyond) 是 是 是 是 是

MonetDB 否 否 是 是 是 是

MySQL 否 是 是 是 是 是

Oracle 是 是 是 是 是 是

OpenLink Virtuoso 是 是 是 是 是 是

Pyrrho DBMS 是 是 是 是 是 是

SQL Anywhere 是 是 是 是 是 是

SQLite 否 否 是 否 否 是

Teradata 否 是 是 是 是 是

Valentina 否 是 是 否 是 否

數據域 遊標 觸發器 函數 12

存儲過程 12

外部調用

註記 (12): 以上函數和存儲過程都是指使用SQL或者過程語言（如PL/SQL、PL/pgSQL等）編寫的內部程序調用。外部調用是指使用其他外部語言，如C、Java等語言編寫的調用。存儲過程是這類調用的籠統稱呼，在不同的供應商系統中，它們往往有着不同的定義。

註記 (13): In Derby, users code functions and procedures in Java.

數據表分區

範圍(Range) 哈希(Hash) 混合（範圍+哈希） 列表(List)

PostgreSQL 是 14

是 14

是 14

是 14

Adaptive Server Enterprise 是 是 否 是

Apache Derby 否 否 否 否

IBM DB2 是 是 是 是

Firebird 否 否 否 否

Informix 是 是 ? ?

Ingres 是 是 是 是

InterBase 否 否 否 否

MaxDB 否 否 否 否

Microsoft SQL Server 是 否 否 否

MonetDB 是 (M5) 是 (M5) 是 (M5) 否

MySQL 是 (5.1 beta) 是 (5.1 beta) 是 (5.1 beta) 是 (5.1 beta)

Oracle 是 是 是 是

OpenLink Virtuoso 是 否 否 否

Pyrrho DBMS 否 否 否 否

SQL Anywhere 否 否 否 否

SQLite 否 否 否 否

Teradata 是 是 是 是

Valentina 否 否 否 否

範圍(Range) 哈希(Hash) 混合（範圍+哈希） 列表(List)

註記 (14): PostgreSQL 8.1 提供了使用check約束實現的數據表分區。範圍、列表以及哈希分區可通過PL/pgSQL或者其他過程語言模擬。

數據庫與模式(Schemas)

SQL標準明確了SQL模式（SQL schema）的定義，然而，許多數據庫對它的實現並不正確。SQL模式是指一個數據庫內部的名字空間，此空間內部的對象可以通過成員操作符.訪問。

一個完整名字的查詢類似這種形式：select * from database.schema.table。

The SQL specification makes clear what an "SQL schema" is; however, different databases implement it wrongly. To compound this confusion the functionality can, when wrongly implemented, overlap with that of the parent-database. An SQL schema is simply a namespace within a database, things within this namespace are addressed using the member operator dot ".". This seems to be a universal amongst all of the implementations.

A true fully (database, schema, and table) qualified query is exemplified as such:select * from database.schema.table

Now, the issue, both a schema and a database can be used to isolate one table, "foo" from another like named table "foo". The following is pseudo code:

select * from db1.foo vs. select * from db2.foo (no explicit schema between db and table)

select * from [db1.]default.foo vs. select * from [db1.]alternate.foo (no explicit db prefix)

The problem that arises is that former MySQL users will mistakenly create multiple databases for one project. In this context MySQL databases are analogous in function to Postgres-schemas, insomuch as Postgres lacks off-the-shelf cross-database functionality that MySQL has. conversely, Postgres has rightfully applied more of the specification, in a sane-bottom-up approach, implementing cross-table, cross-schema, and then left room for future cross-database functionality.

MySQL aliases behind the scenes, schema with database, such that create schema, and create database are analogs. It can be said, that MySQL therefore, has implemented cross-table functionality, skipped schema functionality entirely and provided similar functionality into their implementation of a database. In summary, Postgres fully supports schemas, but lacks some functionality MySQL has with databases, while MySQL doesn't even attempt to support true schemas.

The end result is spin from both communities. While the Postgres community maintains that one database is all that is needed for one project; and MySQL, that schemas have no legitimate purpose when the functionality can be achieved with databases. Postgres adheres to more of the SQL specification, in a more intuitive fashion (bottom-up), while MySQL's pragmatic counterargument allows their users to get the job done without any major drawback.