一个好的数据库要注意什么

如果希望设计出比较好的数据库，有一些专门的规则，称为数据库的设计范式。遵循这些规则，你将设计出良好的数据库。下面将逐一对其进行说明：

1第一范式：它的目标是确保每一列的原子性，如果每列（或属性）都是不可再分的最小数据单元，则满足第一范式。

2第二范式：第二范式则是在第一范式的基础上，更近一层，目标是确保表中的每一列都和主键相关。如果一个关系满足第一范式，并且除了主键意外的其他列，都依赖与该主键，则满足第二范式。例如：订单表（订单编号，产品编号，订购日期，价格，。。。）;该表主要用来表述订单，所以将订单设为主键，而“订购日期”，“价格”这两列与“订单编号”主键相关。但是“产品编号”并不依赖于“订单编号”，该列应当删除，放入产品表中。这样，该表就之描述一件事情：订单信息了。

3第三范式：第三范式在第二范式的基础上更近一层，目标是确保每列都和主键列直接相关，而不是间接相关，如果一个关系满足第二范式，并且除了主键之外的其他列都不依赖与主键列，则满足第三范式。

例如：订单表（订单编号，订购日期，顾客编号，顾客姓名，);初看该表没有问题，满足第二范式，单细看您会发现，“顾客姓名”和“顾客编号”又相关，最后经过传递依赖，“顾客姓名”和“订单编号”相关。为了满足第三范式，我们在设计数据库的时候应该去掉“顾客姓名”列。

说到数据库 我认为不能不先谈数据结构 年 在我初入大学学习计算机编程时 当时的老师就告诉我们说 计算机程序＝数据结构＋算法 尽管现在的程序开发已由面向过程为主逐步过渡到面向对象为主 但我还是深深赞同 年前老师的告诉我们的公式 计算机程序＝数据结构＋算法 面向对象的程序开发 要做的第一件事就是 先分析整个程序中需处理的数据 从中提取出抽象模板 以这个抽象模板设计类 再在其中逐步添加处理其数据的函数(即算法) 最后 再给类中的数据成员和函数划分访问权限 从而实现封装 数据库的最初雏形据说源自美国一个奶牛场的记账薄(纸质的 由此可见 数据库并不一定是存储在电脑里的数据^_^) 里面记录的是该奶牛场的收支账目 程序员在将其整理 录入到电脑中时从中受到启发 当按照规定好的数据结构所采集到的数据量大到一定程度后 出于程序执行效率的考虑 程序员将其中的检索 更新维护等功能分离出来 做成单独调用的模块 这个模块后来就慢慢发展 演变成现在我们所接触到的数据库管理系统(dbms)——程序开发中的一个重要分支 下面进入正题 首先按我个人所接触过的程序给数据库设计人员的功底分一下类 1 没有系统学习过数据结构的程序员 这类程序员的作品往往只是他们的即兴玩具 他们往往习惯只设计有限的几个表 实现某类功能的数据全部塞在一个表中 各表之间几乎毫无关联 网上不少的免费管理软件都是这样的东西 当程序功能有限 数据量不多的时候 其程序运行起来没有什么问题 但是如果用其管理比较重要的数据 风险性非常大 2 系统学习过数据结构 但是还没有开发过对程序效率要求比较高的管理软件的程序员 这类人多半刚从学校毕业不久 他们在设计数据库表结构时 严格按照教科书上的规定 死扣e r图和 nf(别灰心 所有的数据库设计高手都是从这一步开始的) 他们的作品 对于一般的access型轻量级的管理软件 已经够用 但是一旦该系统需要添加新功能 原有的数据库表差不多得进行大换血 3 第二类程序员 在经历过数次程序效率的提升 以及功能升级的折腾后 终于升级成为数据库设计的老鸟 第一类程序员眼中的高人 这类程序员可以胜任二十个表以上的中型商业数据管理系统的开发工作 他们知道该在什么样的情况下保留一定的冗余数据来提高程序效率 而且其设计的数据库可拓展性较好 当用户需要添加新功能时 原有数据库表只需做少量修改即可 4 在经历过上十个类似数据库管理软件的重复设计后 第三类程序员中坚持下来没有转行 而是希望从中找出 偷懒 窍门的有心人会慢慢觉悟 从而完成量变到质变的转换 他们所设计的数据库表结构有一定的远见 能够预测到未来功能升级所需要的数据 从而预先留下伏笔 这类程序员目前大多晋级成数据挖掘方面的高级软件开发人员 5 第三类程序员或第四类程序员 在对现有的各家数据库管理系统的原理和开发都有一定的钻研后 要么在其基础上进行二次开发 要么自行开发一套有自主版权的通用数据库管理系统 我个人正处于第三类的末期 所以下面所列出的一些设计技巧只适合第二类和部分第三类数据库设计人员 同时 由于我很少碰到有兴趣在这方面深钻下去的同行 所以文中难免出现错误和遗漏 在此先行声明 欢迎大家指正 不要藏私哦 ) 一 树型关系的数据表 不少程序员在进行数据库设计的时候都遇到过树型关系的数据 例如常见的类别表 即一个大类 下面有若干个子类 某些子类又有子类这样的情况 当类别不确定 用户希望可以在任意类别下添加新的子类 或者删除某个类别和其下的所有子类 而且预计以后其数量会逐步增长 此时我们就会考虑用一个数据表来保存这些数据 按照教科书上的教导 第二类程序员大概会设计出类似这样的数据表结构 类别表_ (type_table_ )名称类型约束条件说明type_id　 int　 无重复 类别标识 主键type_name　char( ) 不允许为空 类型名称 不允许重复type_father　 int　 不允许为空 该类别的父类别标识 如果是顶节点的话设定为某个唯一值这样的设计短小精悍 完全满足 nf 而且可以满足用户的所有要求 是不是这样就行呢？答案是no！why？我们来估计一下用户希望如何罗列出这个表的数据的 对用户而言 他当然期望按他所设定的层次关系一次罗列出所有的类别 例如这样 总类别类别 类别 类别 类别 类别 类别 类别 类别 类别 ……看看为了实现这样的列表显示(树的先序遍历) 要对上面的表进行多少次检索？注意 尽管类别 可能是在类别 之后添加的记录 答案仍然是n 次 这样的效率对于少量的数据没什么影响 但是日后类型扩充到数十条甚至上百条记录后 单单列一次类型就要检索数十次该表 整个程序的运行效率就不敢恭维了 或许第二类程序员会说 那我再建一个临时数组或临时表 专门保存类型表的先序遍历结果 这样只在第一次运行时检索数十次 再次罗列所有的类型关系时就直接读那个临时数组或临时表就行了 其实 用不着再去分配一块新的内存来保存这些数据 只要对数据表进行一定的扩充 再对添加类型的数量进行一下约束就行了 要完成上面的列表只需一次检索就行了 下面是扩充后的数据表结构 类别表_ (type_table_ )名称类型约束条件　说明type_id　 int无重复　类别标识 主键type_name char( )　不允许为空　类型名称 不允许重复type_father　 int　 不允许为空　该类别的父类别标识 如果是顶节点的话设定为某个唯一值type_layer　 char( )限定 层 初始值为类别的先序遍历 主要为减少检索数据库的次数按照这样的表结构 我们来看看上面例子记录在表中的数据是怎样的 type_id type_name　 type_father　 type_layer 总类别 类别 类别 类别 类别 类别 类别 类别 类别 类别 ……现在按type_layer的大小来检索一下 select from type_table_ order by type_layer列出记录集如下 type_id type_name　 type_father　 type_layer 总类别　 类别 类别 类别 类别 类别 类别 类别 类别 类别 ……现在列出的记录顺序正好是先序遍历的结果 在控制显示类别的层次时 只要对type_layer字段中的数值进行判断 每 位一组 如大于 则向右移 个空格 当然 我这个例子中设定的限制条件是最多 层 每层最多可设 个子类别 只要按用户的需求情况修改一下type_layer的长度和位数 即可更改限制层数和子类别数 其实 上面的设计不单单只在类别表中用到 网上某些可按树型列表显示的论坛程序大多采用类似的设计 或许有人认为 type_table_ 中的type_father字段是冗余数据 可以除去 如果这样 在插入 删除某个类别的时候 就得对 type_layer 的内容进行比较繁琐的判定 所以我并没有消去type_father字段 这也正符合数据库设计中适当保留冗余数据的来降低程序复杂度的原则 后面我会举一个故意增加数据冗余的案例 二 商品信息表的设计 假设你是一家百货公司电脑部的开发人员 某天老板要求你为公司开发一套网上电子商务平台 该百货公司有数千种商品出售 不过目前仅打算先在网上销售数十种方便运输的商品 当然 以后可能会陆续在该电子商务平台上增加新的商品出售 现在开始进行该平台数据库的商品信息表的设计 每种出售的商品都 lishixinzhi/Article/program/Oracle/201311/17002

步骤如下：

1、需求分析阶段

进行数据库设计首先必须准确了解与分析用户需求（包括数据与处理）。需求分析是整个设计过程的基础，是最困难和最耗费时间的一步。作为“地基”的需求分析是否做得充分与准确，决定了在其上构建数据库“大厦”的速度与质量。需求分析做的不好，可能会导致整个数据库设计返工重做。

2、概念结构设计阶段

概念结构设计阶段是整个数据库设计的关键，它通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型。

3、逻辑结构设计阶段

逻辑结构设计是将概念结构转换为某个数据库管理系统所支持的数据模型，并对其进行优化。

3、物理设计阶段

物理结构设计师为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方式）。

5、数据库实施阶段

在数据库实施阶段，设计人员运用数据库管理系统提供数据库语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编写与调试应用程序，组织数据入库，并进行测试运行。

6、数据库运行和维护阶段

数据库应用系统经过试运行后即可投入正式运行，在数据库系统运行过程中必须不断对其进行评估、调整与修改。

以上就是关于一个好的数据库要注意什么全部的内容，包括:一个好的数据库要注意什么、新手浅谈数据库中的设计技巧(一)、数据库设计步骤等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！