关系数据库模型支持了SQL语言的发展并且拥有强大的理论基础为后盾(基于一阶的谓词逻辑)目前SQL已经成为定义和操纵关系数据库的标准语言
关系数据模型的另一个好处在于它的简单性适合联机事务处理(OLTP)支持数据独立性但是关系数据模型特别是RDBMS同样存在许多的不足之处详细内容请参考下文
一对现实世界实体的表达能力比较弱
规范化通常导致表与现实世界中的实体不对应它将现实世界中的实体分割成几张表来显示以物理表示法来反映实体结构这样效率会比较差常常要在查询处理中进行很多连接操作
二语义过载
关系模型表达数据和数据间关系的构造只有一种——表例如为了表达实体A和实体B之间的多对多(*:*)关系我们需要创建三张表两个分别用于表达实体A和B第三张表用于表达实体间的关系它没有一种机制来区分实体和关系也无法区分在实体间存在的不同种类的关系例如一个:*关系可能是HasSupervisesManages等等如果可以进行区分也许我们就可以将语义构建到操作中所以我们说关系模型语义过载了
三不能很好的支持业务规则
很多商业化系统不能完全支持实体和参照完整性域等业务规则所以需要将它们内置到应用程序中这样当然是危险的而且容易导致做重复的工作更糟糕的是可能还会引起不一致现象而且在关系模型中不支持其他类型的业务规则这又意味着它们需要被构建到DBMS或应用程序中
四有限的操作
关系模型只有一些固定的操作集例如面向集合和记录的操作操作是在SQL规格说明中提供的但是SQL目前不允许指定新的操作因此在给许多现实世界对象的行为建模就有了太多的限制例如一个GIS应用程序典型的使用点线线组多边形和一些处理距离交叉点和包含关系的操作
五处理递归查询困难
数据的原子性意味着在关系模型中不允许出现重复的数据组这样就导致了处理递归查询极为困难递归查询就是那些有关表和自身直接或间接的关系的查询为了解决这个问题SQL可以嵌入在一个高级程序设计语言中由高级程序设计语言来提供支持反复操作的功能而且很多RDBMS提供了具有类似结构的报表书写程序不管是哪种情况都是应用程序而不是系统的内在功能提供了所需的功能
六阻抗失配
直到最新版本的SQL标准都缺少完全的计算功能为了解决这个问题并且提供更多的灵活性SQL标准提供嵌入式SQL来帮助开发更加复杂的数据库应用程序但是这引起了阻抗不匹配(impedance mismatch)的问题因为我们将两种不同的程序设计模式混合在了一起
SQL是一种处理行数据的声明性语言而诸如C语言这样的高级语言则是过程化的语言一次只能处理一行数据
SQL和GL使用不同的模型来表达数据比如SQL提供内置的数据类型Date(日期型)和Interval(时间间隔型)而在传统的编程语言中却没有这样的类型因此就需要应用程序在两种表示法之间进行转换而这样做无论从程序设计的工作量还是运行时资源的使用来看都是低效的而且由于我们使用两种不同的系统因此不可能将类型检测作为一个整体自动进行
注SQL标准(SQL)通过引入许多新的特征已经弥补了上文中讲述的一些不足之处
