基于第三范式数据库表的基本设计

本文首先讨论了基于第三范式的数据库表的基本设计,着重论述了建立主键和索引的策略和方案,然后从数据库表的扩展设计和库表对象的放置等角度概述了数据库管理系统的优化方案。

1.简介

数据库优化的目标无非是避免磁盘I/O瓶颈、减少CPU利用率和减少资源竞争。为了便于读者阅读和理解,笔者参阅了Sybase、Informix和Oracle等大型数据库系统参考资料,基于多年的工程实践经验,从基本表设计、扩展设计和数据库表对象放置等角度进行讨论,着重讨论了如何避免磁盘I/O瓶颈和减少资源竞争,相信读者会一目了然。

2.基于第三范式的基本表设计

在基于表驱动的信息管理系统(MIS)中,基本表的设计规范是第三范式(3NF)。第三范式的基本特征是非主键属性只依赖于主键属性。基于第三范式的数据库表设计具有很多优点:一是消除了冗余数据,节省了磁盘存储空间;二是有良好的数据完整性限制,即基于主外键的参照完整限制和基于主键的实体完整性限制,这使得数据容易维护,也容易移植和更新;三是数据的可逆性好,在做连接(Join)查询或者合并表时不遗漏、也不重复;四是因消除了冗余数据(冗余列),在查询(Select)时每个数据页存的数据行就多,这样就有效地减少了逻辑I/O,每个Cash存的页面就多,也减少物理I/O;五是对大多数事务(Transaction)而言,运行性能好;六是物理设计(Physical Design)的机动性较大,能满足日益增长的用户需求。

在基本表设计中,表的主键、外键、索引设计占有非常重要的地位,但系统设计人员往往只注重于满足用户要求,而没有从系统优化的高度来认识和重视它们。实际上,它们与系统的运行性能密切相关。现在从系统数据库优化角度讨论这些基本概念及其重要意义:

(1)主键(Primary Key):主键被用于复杂的SQL语句时,频繁地在数据访问中被用到。一个表只有一个主键。主键应该有固定值(不能为Null或缺省值,要有相对稳定性),不含代码信息,易访问。把常用(众所周知)的列作为主键才有意义。短主键最佳(小于25bytes),主键的长短影响索引的大小,索引的大小影响索引页的大小,从而影响磁盘I/O。主键分为自然主键和人为主键。自然主键由实体的属性构成,自然主键可以是复合性的,在形成复合主键时,主键列不能太多,复合主键使得Join*作复杂化、也增加了外键表的大小。人为主键是,在没有合适的自然属性键、或自然属性复杂或灵敏度高时,人为形成的。人为主键一般是整型值(满足最小化要求),没有实际意义,也略微增加了表的大小;但减少了把它作为外键的表的大小。

(2)外键(Foreign Key):外键的作用是建立关系型数据库中表之间的关系(参照完整性),主键只能从独立的实体迁移到非独立的实体,成为后者的一个属性,被称为外键。

(3)索引(Index):利用索引优化系统性能是显而易见的,对所有常用于查询中的Where子句的列和所有用于排序的列创建索引,可以避免整表扫描或访问,在不改变表的物理结构的情况下,直接访问特定的数据列,这样减少数据存取时间;利用索引可以优化或排除耗时的分类*作;把数据分散到不同的页面上,就分散了插入的数据;主键自动建立了唯一索引,因此唯一索引也能确保数据的唯一性(即实体完整性);索引码越小,定位就越直接;新建的索引效能最好,因此定期更新索引非常必要。索引也有代价:有空间开销,建立它也要花费时间,在进行Insert、Delete和Update*作时,也有维护代价。索引有两种:聚族索引和非聚族索引。一个表只能有一个聚族索引,可有多个非聚族索引。使用聚族索引查询数据要比使用非聚族索引快。在建索引前,应利用数据库系统函数估算索引的大小。

时间: 2024-04-11 17:59:27

基于第三范式数据库表的基本设计的相关文章

基于ORACLE数据库的循环建表及循环创建存储过程的SQL语句实现

一.概述 在实际的软件开发项目中,我们经常会遇到需要创建多个相同类型的数据库表或存储过程的时候.例如,如果按照身份证号码的尾号来分表,那么就需要创建10个用户信息表,尾号相同的用户信息放在同一个表中. 对于类型相同的多个表,我们可以逐个建立,也可以采用循环的方法来建立.与之相对应的,可以用一个存储过程实现对所有表的操作,也可以循环建立存储过程,每个存储过程实现对某个特定表的操作. 本文中,我们建立10个员工信息表,每个表中包含员工工号(8位)和年龄字段,以工号的最后一位来分表.同时,我们建立存储

SQL SERVER数据库表主键设计

1. 序言 当前,随着信息量的急剧增加,对于数据的存储和管理方式,各企业都逐渐摆脱了之前的依靠文件系统(文本文件或者Excel)或者一些桌面型的小型数据库系统(如Access.FoxBASE或者DBase)的状态,转而通过一些大型数据库来管理企业的信息.这些大型数据库系统包括Oracle.MS SQL Server或者IBM DB2.尽管目前数据库系统也在向面向对象的数据库系统方向发展,但是上述的传统的关系型数据库系统依然占据着主要位置. 笔者从九十年代末开始以关系型数据库系统为基础为客户进行管

XML 文档与数据库表

  包括SQL Server 7.0 在内的SQL Server 系列版本并不提供XML. 支持开发人员以前不得不使用一个XML 分析器,如微软的XML 分析器(MSXML),而且它们必须编写自己的代码来处理细节:把不同的元素从XML 文档中提取出来并按需要把它们放进关系表的不同部分,然后访问关系表:或者编写代码将数据从数据库表中提取出来,再以正确的格式放回到XML 文档中.当我们在享受XML 所带来的好处时,我们常会发现自己在开发Web 应用程序时不得不应付这样的工作,而且在开发不同的Web

提前认识软件开发(27) 数据库表及索引的创建

数据表(或称表),是数据库最重要的组成部分之一.数据库只是一个框架,数据表才是其实质的内容.举个例子来说,数据库就像是一座空旷的房子,而数据表是里面的家具,没有家具的房子只是一个空壳而已.根据信息的分类情况,一个数据库中可能包含若干个不同用途的数据表. 表结构有简单.有复杂,这就对开发人员提出了要求.如何设计一个表的字段才是最好的?表的字段如何命名?如何定义表字段的类型?如何建立索引?等等. 1. 修改之前的建表脚本 在作者从事过的某项目中,有一个建表脚本(基于Sybase数据库)样例如下: -

MS SQL基础教程:XML文档与数据库表

包括SQL Server 7.0 在内的SQL Server 系列版本并不提供XML. 支持开发人员以前不得不使用一个XML 分析器,如微软的XML 分析器(MSXML),而且它们必须编写自己的代码来处理细节:把不同的元素从XML 文档中提取出来并按需要把它们放进关系表的不同部分,然后访问关系表:或者编写代码将数据从数据库表中提取出来,再以正确的格式放回到XML 文档中.当我们在享受XML 所带来的好处时,我们常会发现自己在开发Web 应用程序时不得不应付这样的工作,而且在开发不同的Web 应用

PHP基于MySQL数据库实现对象持久层的方法

 本文实例讲述了PHP基于MySQL数据库实现对象持久层的方法.分享给大家供大家参考.具体如下: 心血来潮,做了一下PHP的对象到数据库的简单持久层. 不常用PHP,对PHP也不熟,关于PHP反射的大部分内容都是现学的. 目前功能比较弱,只是完成一些简单的工作,对象之间的关系还没法映射,并且对象的成员只能支持string或者integer两种类型的. 成员变量的值也没有转义一下... 下面就贴一下代码: 首先是数据库的相关定义,该文件定义了数据库的连接属性: ? 1 2 3 4 5 6 7 8

外键-数据库 表的设计问题。

问题描述 数据库 表的设计问题. 现在有三个表: 1.餐厅(主键:餐厅ID,....) 2.菜单(外键:餐厅ID,菜名,....) 3.菜的评价(外键:餐厅ID,菜名,....) 目标: 1.菜单里, 餐厅ID+菜名的组合是唯一的.(一道菜只在一个店的菜单出现一次) 2.菜的评价里,餐厅ID+菜名的组合不是唯一的.(某餐厅的某道菜能有多个评价) 三个表的设计应该如何才能实现目标呢? 解决方案 大体结构已经成形,其他方面注意一下基本的第三范式即可 解决方案二: 你这不已经设计出来了吗,你这个结构就

WordPress数据库表及字段详解

今天熊哥在朋友的博客看到关于wordpress数据库的介绍,感觉很有用,相信对同样在使用wordpress的同学也很有用,所以就拿过来分享一下.希望对自己和大家有所帮助. [废话] 记得刚接触网站时对数据库一点概念也没有,那时公司网站要换服务器,于是就单纯的转移了网站文件,结果可想而知.一翻折腾,在糊里糊涂中按网上的教程终于搞定,享受成就感时也第一次接触了数据库.那时感觉数据库高端深奥遥远,从没想过自己以后会跟数据库再有交集:而后,自己成为一名数据库工程师时也没想起当年数据库曾给自己带来困扰.现

hibernate-Hibernate和数据库表关联关系的问题

问题描述 Hibernate和数据库表关联关系的问题 我想问一下在实际的项目开发中,Hibernate的关联关系和数据库表的关联关系需要同时建立吗?就是既在持久化对象里写关联关系又在数据库里建外键 解决方案 你好,这个问题也曾困扰过我,以下经验与你分享: 引入Hibernate框架的意义是为了让开发更靠近面向对象的思想,因此理论上需要使用的是面向对象的数据库,但是现今未出现较好的OO数据库, 所以使用关系型数据库就一定会面临偏离OO的部分. 按照OO理论,在Hibernate中,对象抽象成类,那