关係型资料库系统 _生活百科

关係型资料库系统【关係型资料库系统】关係型资料库管理系统 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.