關係型資料庫管理系統 RDBMS在E.F.Codd博士發表的論文《大規模共享數據銀行的關係型模型》(Communications of the ACM雜誌1970年6月刊)基礎上設計出來的。
基本介紹
- 中文名：關係型資料庫系統
- 外文名：Communications of the
- 簡稱：ACM
- 發表時間 ：1970年6月
它通過數據、關係和對數據的約束三者組成的數據模型來存放和管理數據。三十多年來，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.
