MySQL数据库表的基础操作

一，MySQL数据类型分类

MySQL支持多种数据类型，大致分为三类：数值型，日期/时间型和字符串（字符）类型

1，数值型

MySQL支持所有标准sql数值数据类型。



也就是说分为整数或者小数两种类型的，比较常用的是整数类型的是int（也可以说integer），比较常用的小数类型的是decimal。

小数decimal类型的格式：decimal （总位数，小数部分的位数）

例如：价格 decimal（5,3）                 99.987          

2，日期/时间型

日期和时间类型为DATETIME、DATE、TIMESTAMP、TIME和YEAR

每个时间类型有一个有效值范围和一个"零"值，当指定不合法的MySQL不能表示的值时使用"零"值。

每个时间类型有一个有效值范围和一个"零"值，当指定不合法的MySQL不能表示的值时使用"零"值。



时间类型最常用的是datetime。

3，字符串(字符)类型



 



字符串类型的，最常用的是char和varchar。



二，Navicat

Navicat 是一套快速、可靠并价格相宜的数据库管理工具，专为简化数据库的管理及降低系统管理成本而设。它的设计符合数据库管理员、开发人员及中小企业的需要。Navicat 是以直觉化的图形用户界面而建的，让你可以以安全并且简单的方式创建、组织、访问并共用信息。

它可以用来对本机或远程的 MySQL、SQL Server、SQLite、Oracle 及 PostgreSQL 数据库进行管理及开发。

Navicat适用于三种平台 - Microsoft Windows、Mac OS X 及Linux。

所以今后数据库的操作，我都是在Navicat中进行。

三，表的创建语法

Create table 表名(

属性名1 数据类型 [约束条件],

属性名2 数据类型 [约束条件],

属性名3 数据类型 [约束条件]

);

[ ]中括号中的内容是可选内容，

最后一个属性后没有逗号。



单行注释的时候                    --空一格 注释的内容     

多行注释的时候                    /*注释内容*/ 

下面我们一起来运行一下试试看！

①先选中刚才写的内容，然后点击鼠标的右键，再点击运行已选择的。







②刷新一下，找到我们创建的student表，点击第二个和第三个都可以查看我们创建的student表。



点击设计表，是查看表结构的



点击第二个打开表（快速），是查看表中存储的内容



四，直接手动创建表

1，先选中表，然后右键点击新建表







2，然后在表里面该输入就输入，该选择就选择，就可以好了，按键盘上的上下箭头，就可以继续插入第2行，第3行......





3，完善好表的内容以后，按Ctrl+S保存，然后会让输入表名，输入表名以后点击确定，就手动创建表成功了。





五，直接手动填写表

1，点击打开表（快速）



2，直接在表里填写就可以



3，点击下面的“+”，就可以继续填写第2行，第3行..........





4，填写完表以后，点击下面的“✓”就可以了



六，删除表

语法格式                 drop table 表名;

删除多个表              格式          drop table 表名1,表名2...;

假如我要删除mydb01的数据库中的a表

1，首先我要切换数据库    格式          use 数据库的名字

输入use mydb01



2，选中刚才写的内容，右键点击运行已经选择的



3，输入drop table a;



4，还是先选中，然后右键点击运行已选择的



5，在mytb01数据库中，右键点击表，然后点击刷新，就删除了



七，修改表

1，添加列(属性)

alter table 表名 add 属性名 数据类型;

2，删除列(属性)

alter table 表名 drop 属性名;

3，修改属性

alter table 表名  modify 属性名 数据类型;

4，修改字段名

alter table 表名  change  旧字段名  新字段名 数据类型;

5，显示表结构

desc 表名;

八,把文件中的表格导入到MySQL数据库中

1，创建一个数据库



2，选择创建好的表右键，然后点击运行SQL文件



3，点击我箭头指向的地方



4，找到自己存放表的文件





5，选中自己想要导入的文件以后，点击打开



6，点击开始，导入完以后会显示 successfully，再点击关闭





7，点击刷新，导入的表就显示出来了

    前面零零总总的看了看一些规范。  那么这里则要结合自己的实践谈谈自己的理解。

    之前设计数据库的时候主要存在以下一些问题：

          1.对于关系型数据库来说，如何开始设计？  当然这里不是指常规的软件工程那样的步骤。  就java而言，我所知道的就有，一种先在数据库中设计，然后建立相应的实体。   另外一种就是采用数据关系映射的关系，直接用hibernate产品帮我们建表。  前者是老牌程序员较喜欢的。  后者是比较简便的办法，但是会违背一些性能规范，也就是带来性能的问题。  在小项目里面应该还是影响不大的。  此外，需要了解hibernate的映射规则，相关的注解等。

          2.数据库的表名如何取？  如何能够保证一致性，并且增强团队协作的能力？   那么以后就确定一个标准，比如统一使用 tb_xxx，或者统一使用 t_xxx。 

          3.设计好数据库以后，如果不用hibernate帮我们解决查询的连接表的问题，我们需要自己手写很多的连接sql语句。  比如我们用mybatis的时候，如何能够在看到让人望而却步的枯燥的代码中解放出来，也就是不写sql语句，同时保证性能。 这就成了一个问题。  不过目前能想到的还是用hibernate吧，并且配合它的关于合法性的一些注解，还解放了部分业务层的代码，何乐而不为？？

          4.数据表字段名的确定，以及属性的确定。  事实上，不是这里的命名，而是所有要命名的地方都存在命名的一个不确定性。 这对需要很多命名的地方，如android 的页面设计，html的页面设计中都存在这样的问题。。    属性的确定，则主要来自于内心的不自信，也就是练的比较少，不敢确定属性。。  

          5. 为了性能的需要，都推荐将外键约束舍去，而不在数据库中声明。 这样的话会增加业务层的代码，也就是增加开发人员的任务。 对企业级开发应该是适用的，但是对于个人的练习，应该以人为主。。   嗯！！  语言从低级到高级本质也就是为了亲人性，所以对待性能的问题，一定要有一定的忍耐度。。。

------------------------------------------------------------------------------------------------------------------------- 

        嗯，中间有点事情耽搁了一下。 下面就上面的观点所代表的Hibernate的注解相关的API。经过不断的查找，总算找到了自己想要的信息：写的太好，地址。。  才发现自己长期纠结的问题有个核心的问题就是映射关系的问题。 一与一，多与一，多与多，单向与双向等等。。。

        跟着这个大神的思路，将整个过程过一遍吧。  写的实在是很感动。

        首先，数据关系映射中两端的关系不分方向有三种，分方向有四种。即 一对一，一对多，多对一，多对多。

        但是，hibernate的所谓单向多向，并不是说代表方向问题，它的核心在于它的级联操作，代表的是数据操作问题。所以没有可比性。

多与一：

       关于这种关系，在哪端维护的问题。  思考一个老板记住员工容易还是所有员工记住老板容易就行了。   这样做可以相对的冗余度要低一些。  （也就是在多的一端。  因为在多的一段增加的是属性列。  而如果在少的一端维护，则要增加元组。  开销肯定是要大一些的）。  基于这个理念，多对一与一对多最终生成的表格是一样的。

        但是需要注意，他们的级联操作逻辑是不同的。针对查询而言，  多对一时，操作多时，可以将一查出来。   一对多的时候，操作一可以将多查出来。    针对插入而言，因为一与多都是在多的一端维护关系，所以，他们的关系存在一种不对等性。。 如操作多的时候，并不知道一的枚举有哪些。

   他们的构成：





 

       cascade级联，意思是指两个对象之间的操作联动关系，即对象之间的连锁反应，只能影响数据更新操作。 可选项有： all,none,save-update,delete。   

       为了解决单向级联方面的缺陷，引入了双向映射。它们的构成：



   实现方式为：  在多的一端的关联属性上加上 many-to-one,一对多在对应的一的关系上加上 one-to-many的映射。  需要注意，理解方面  to 之前指的是this对象，to 之后指的是该属性对象。   此外，这样的话会增加程序的冗余度。 因为他实际上是即有元组的增加，又有属性列的增加。   同时，它提供一个inverse参数。  若为false（默认），表示本端可以维护关系。否则反之。  且，多与一只有一方负责维护关系。推荐的是用 一维护关系，但是又保证了数据间的对等性。   最后，它映射的表字段会有所变化。

一与一：

     实现方式有两种： 一对一主键关联映射；  以及  唯一外键映射。

      单向一对一的构成：

         

          双向一对一的构成：

            

             一对一主键双向关联映射与单向关联映射在存储方式上没有什么不同。

             一对一唯一外键的实现：

                   

             需注意，这个时候在发起的一的一方，需要使用many-to-one，并且加一个unique="true"的限定。

             唯一外键的双向：

                       

              它们的配合是： many-to-one  以及 one-to-one.

多与多：

      实现途径：中间表。

      也分为单向与双向。

      单向：使用many-to-many

             

       双向：

              

             两边都用many-to-many。此外，它们的中间表名必须一样。

总结： 单向与多向代表数据透明度。

     二者关系为单向中，主动发总会有被动方的属性。（包括单向一对多，多对一，一对一，多对多）。 

     双向包括： 一对多，一对一，多对多。

树形结构的数据库表Schema设计

    程序设计过程中，我们常常用树形结构来表征某些数据的关联关系，如企业上下级部门、栏目结构、商品分类等等，通常而言，这些树状结构需要借助于数据库完成持久化。然而目前的各种基于关系的数据库，都是以二维表的形式记录存储数据信息，因此是不能直接将Tree存入DBMS，设计合适的Schema及其对应的CRUD算法是实现关系型数据库中存储树形结构的关键。
    理想中树形结构应该具备如下特征：数据存储冗余度小、直观性强；检索遍历过程简单高效；节点增删改查CRUD操作高效。无意中在网上搜索到一种很巧妙的设计，原文是英文，看过后感觉有点意思，于是便整理了一下。本文将介绍两种树形结构的Schema设计方案：一种是直观而简单的设计思路，另一种是基于左右值编码的改进方案。
一、基本数据
    本文列举了一个食品族谱的例子进行讲解，通过类别、颜色和品种组织食品，树形结构图如下：
二、继承关系驱动的Schema设计
    对树形结构最直观的分析莫过于节点之间的继承关系上，通过显示地描述某一节点的父节点，从而能够建立二维的关系表，则这种方案的Tree表结构通常设计为：{Node_id,Parent_id}，上述数据可以描述为如下图所示：

    这种方案的优点很明显：设计和实现自然而然，非常直观和方便。缺点当然也是非常的突出：由于直接地记录了节点之间的继承关系，因此对Tree的任何CRUD操作都将是低效的，这主要归根于频繁的“递归”操作，递归过程不断地访问数据库，每次数据库IO都会有时间开销。当然，这种方案并非没有用武之地，在Tree规模相对较小的情况下，我们可以借助于缓存机制来做优化，将Tree的信息载入内存进行处理，避免直接对数据库IO操作的性能开销。
三、基于左右值编码的Schema设计
    在基于数据库的一般应用中，查询的需求总要大于删除和修改。为了避免对于树形结构查询时的“递归”过程，基于Tree的前序遍历设计一种全新的无递归查询、无限分组的左右值编码方案，来保存该树的数据。

    第一次看见这种表结构，相信大部分人都不清楚左值（Lft）和右值（Rgt）是如何计算出来的，而且这种表设计似乎并没有保存父子节点的继承关系。但当你用手指指着表中的数字从1数到18，你应该会发现点什么吧。对，你手指移动的顺序就是对这棵树进行前序遍历的顺序，如下图所示。当我们从根节点Food左侧开始，标记为1，并沿前序遍历的方向，依次在遍历的路径上标注数字，最后我们回到了根节点Food，并在右边写上了18。
    第一次看见这种表结构，相信大部分人都不清楚左值（Lft）和右值（Rgt）是如何计算出来的，而且这种表设计似乎并没有保存父子节点的继承关系。但当你用手指指着表中的数字从1数到18，你应该会发现点什么吧。对，你手指移动的顺序就是对这棵树进行前序遍历的顺序，如下图所示。当我们从根节点Food左侧开始，标记为1，并沿前序遍历的方向，依次在遍历的路径上标注数字，最后我们回到了根节点Food，并在右边写上了18。
    依据此设计，我们可以推断出所有左值大于2，并且右值小于11的节点都是Fruit的后续节点，整棵树的结构通过左值和右值存储了下来。然而，这还不够，我们的目的是能够对树进行CRUD操作，即需要构造出与之配套的相关算法。
 四、树形结构CRUD算法
（1）获取某节点的子孙节点
    只需要一条SQL语句，即可返回该节点子孙节点的前序遍历列表，以Fruit为例：SELECT* FROM Tree WHERE Lft BETWEEN 2 AND 11 ORDER BY Lft ASC。查询结果如下所示：
    那么某个节点到底有多少的子孙节点呢？通过该节点的左、右值我们可以将其子孙节点圈进来，则子孙总数 = (右值 – 左值– 1) / 2，以Fruit为例，其子孙总数为：(11 –2 – 1) / 2 = 4。同时，为了更为直观地展现树形结构，我们需要知道节点在树中所处的层次，通过左、右值的SQL查询即可实现，以Fruit为例：SELECTCOUNT(*) FROM Tree WHERE Lft <= 2 AND Rgt >=11。为了方便描述，我们可以为Tree建立一个视图，添加一个层次数列，该列数值可以写一个自定义函数来计算，函数定义如下：
[sql] view plain copy
CREATE FUNCTION dbo.CountLayer  
(  
    @node_id int  
)  
RETURNS int  
AS  
begin  
    declare @result int  
    set @result = 0  
    declare @lft int  
    declare @rgt int  
    if exists(select Node_id from Tree where Node_id = @node_id)  
    begin  
        select @lft = Lft, @rgt = Rgt from Tree where node_id = @node_id  
        select @result = count(*) from Tree where Lft <= @lft and Rgt >= @rgt  
    end  
    return @result  
end  
GO  
    基于层次计算函数，我们创建一个视图，添加了新的记录节点层次的数列：
[sql] view plain copy
CREATE VIEW dbo.TreeView  
AS  
SELECT Node_id, Name, Lft, Rgt, dbo.CountLayer(Node_id) AS Layer FROM dbo.Tree ORDER BY Lft  
GO  
    创建存储过程，用于计算给定节点的所有子孙节点及相应的层次：
[sql] view plain copy
CREATE PROCEDURE [dbo].[GetChildrenNodeList]  
(  
    @node_id int  
)  
AS  
declare @lft int  
declare @rgt int  
if exists(select Node_id from Tree where node_id = @node_id)  
    begin  
        select @lft = Lft, @rgt = Rgt from Tree where Node_id = @node_id  
        select * from TreeView where Lft between @lft and @rgt order by Lft ASC  
    end  
GO  
    现在，我们使用上面的存储过程来计算节点Fruit所有子孙节点及对应层次，查询结果如下：

    从上面的实现中，我们可以看出采用左右值编码的设计方案，在进行树的查询遍历时，只需要进行2次数据库查询，消除了递归，再加上查询条件都是数字的比较，查询的效率是极高的，随着树规模的不断扩大，基于左右值编码的设计方案将比传统的递归方案查询效率提高更多。当然，前面我们只给出了一个简单的获取节点子孙的算法，真正地使用这棵树我们需要实现插入、删除同层平移节点等功能。
 （2）获取某节点的族谱路径
    假定我们要获得某节点的族谱路径，则根据左、右值分析只需要一条SQL语句即可完成，以Fruit为例：SELECT* FROM Tree WHERE Lft < 2 AND Rgt > 11 ORDER BY Lft ASC ，相对完整的存储过程：
[sql] view plain copy
CREATE PROCEDURE [dbo].[GetParentNodePath]  
(  
    @node_id int  
)  
AS  
declare @lft int  
declare @rgt int  
if exists(select Node_id from Tree where Node_id = @node_id)  
    begin  
        select @lft = Lft, @rgt = Rgt from Tree where Node_id = @node_id  
        select * from TreeView where Lft < @lft and Rgt > @rgt order by Lft ASC  
    end  
GO  
（3）为某节点添加子孙节点
    假定我们要在节点“Red”下添加一个新的子节点“Apple”，该树将变成如下图所示，其中红色节点为新增节点。

    仔细观察图中节点左右值变化，相信大家都应该能够推断出如何写SQL脚本了吧。我们可以给出相对完整的插入子节点的存储过程：
[sql] view plain copy
CREATE PROCEDURE [dbo].[AddSubNode]  
(  
    @node_id int,  
    @node_name varchar(50)  
)  
AS  
declare @rgt int  
if exists(select Node_id from Tree where Node_id = @node_id)  
    begin  
        SET XACT_ABORT ON  
        BEGIN TRANSCTION  
        select @rgt = Rgt from Tree where Node_id = @node_id  
        update Tree set Rgt = Rgt + 2 where Rgt >= @rgt  
        update Tree set Lft = Lft + 2 where Lft >= @rgt  
        insert into Tree(Name, Lft, Rgt) values(@node_name, @rgt, @rgt + 1)  
        COMMIT TRANSACTION  
        SET XACT_ABORT OFF  
    end  
GO  
（4）删除某节点
    如果我们想要删除某个节点，会同时删除该节点的所有子孙节点，而这些被删除的节点的个数为：(被删除节点的右值 – 被删除节点的左值+ 1) / 2，而剩下的节点左、右值在大于被删除节点左、右值的情况下会进行调整。来看看树会发生什么变化，以Beef为例，删除效果如下图所示。
    则我们可以构造出相应的存储过程：
[sql] view plain copy
CREATE PROCEDURE [dbo].[DelNode]  
(  
    @node_id int  
)  
AS  
declare @lft int  
declare @rgt int  
if exists(select Node_id from Tree where Node_id = @node_id)  
    begin  
        SET XACT_ABORT ON  
        BEGIN TRANSCTION  
            select @lft = Lft, @rgt = Rgt from Tree where Node_id = @node_id  
            delete from Tree where Lft >= @lft and Rgt <= @rgt  
            update Tree set Lft = Lft – (@rgt - @lft + 1) where Lft > @lft  
            update Tree set Rgt = Rgt – (@rgt - @lft + 1) where Rgt > @rgt  
            COMMIT TRANSACTION  
        SET XACT_ABORT OFF  
    end  
GO  
五、总结
    我们可以对这种通过左右值编码实现无限分组的树形结构Schema设计方案做一个总结：
    （1）优点：在消除了递归操作的前提下实现了无限分组，而且查询条件是基于整形数字的比较，效率很高。
    （2）缺点：节点的添加、删除及修改代价较大，将会涉及到表中多方面数据的改动。
    当然，本文只给出了几种比较常见的CRUD算法的实现，我们同样可以自己添加诸如同层节点平移、节点下移、节点上移等操作。有兴趣的朋友可以自己动手编码实现一下，这里不在列举了。值得注意的是，实现这些算法可能会比较麻烦，会涉及到很多条update语句的顺序执行，如果顺序调度考虑不周详，出现Bug的话将会对整个树形结构表产生惊人的破坏。因此，在对树形结构进行大规模修改的时候，可以采用临时表做中介，以降低代码的复杂度，同时，强烈推荐在做修改之前对表进行完整备份，以备不时之需。在以查询为主的绝大多数基于数据库的应用系统中，该方案相比传统的由父子继承关系构建的数据库Schema更为适用。

转载自：http://www.javaeye.com/topic/281611

1. 原始单据与实体之间的关系 
　　可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。 
在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。 
这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。 

　　〖例1〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。 
　　　　　　  这就是“一张原始单证对应多个实体”的典型例子。 

2. 主键与外键 
　　一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键 
　　(因为它无子孙), 但必须要有外键(因为它有父亲)。 

　　主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专 
　　家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核 
　　心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。 

3. 基本表的性质 
　　基本表与中间表、临时表不同，因为它具有如下四个特性： 
　　 (1) 原子性。基本表中的字段是不可再分解的。 
　　 (2) 原始性。基本表中的记录是原始数据（基础数据）的记录。 
　　 (3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。 
　　 (4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。 
　　理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。 

4. 范式标准 
　　基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。 
　　为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。 

　　〖例2〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式， 
　　因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段， 
　　可以提高查询统计的速度，这就是以空间换时间的作法。 
　　在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和 
　　“数量”这样的列被称为“数据列”。 

　　表1 商品表的表结构 
　　商品名称 商品型号 单价 数量 金额 
　　电视机 29吋 2,500 40 100,000 
　　 
5. 通俗地理解三个范式 
　　通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解 
　　三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)： 
　　第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解； 
　　第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性； 
　　第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。 

　　没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降 
　　低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理 
　　数据模型设计时考虑。降低范式就是增加字段，允许冗余。 

6. 要善于识别与正确处理多对多的关系 
　　若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一 
　　个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个 
　　实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处 
　　理多对多的关系。 

　　〖例3〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一 
　　个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之 
　　间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借书，1表示还书)，另外， 
　　它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。 

7. 主键PK的取值方法 
　　 PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义 
　　的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引 
　　占用空间大，而且速度也慢。 

8. 正确认识数据冗余 
　　主键与外键在多表中的重复出现, 不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重 
　　复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。 

　　〖例4〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余， 
　　而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可 
　　能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。 

9. E--R图没有标准答案 
　　信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容， 
　　就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E—R图的标准是： 
　　结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。 

10 . 视图技术在数据库设计中很有用 
　　与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的 
　　一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、 
　　提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 
　　 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。 

　　对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完 
　　成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。 
　　并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”， 
　　才能直接在基本表上操作。请读者想想：这是为什么？ 

11. 中间表、报表和临时表 
　　中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓 
　　库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员 
　　自己用程序自动维护。 

12. 完整性约束表现在三个方面 
　　域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通 
　　过它定义字段的值城。 
　　参照完整性：用PK、FK、表级触发器来实现。 
　　用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。 

13. 防止数据库设计打补丁的方法是“三少原则” 
　　 (1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的 
　　　　实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计； 

　　 (2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组 
　　　　合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间； 

　　 (3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗 
　　　　余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许 
　　　　多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简 
　　　　单，有的人就是不习惯、不采纳、不执行。 

　　数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点， 
　　不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功 
　　能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性) 的E--R图，要好得多。 

　　提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成 
　　为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据 
　　共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数 
　　就会越少。 

　　提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意 
　　设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表 
　　杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。 

　　 “三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的 
　　原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法” 
　　设计数据库的理论依据。 

14. 提高数据库运行效率的办法 
　　在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是： 
　　 (1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。 
　　 (2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方 
　　　　式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。 
　　 (3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键 
　　　　PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则 
　　　　垂直分割该表，将原来的一个表分解为两个表。 
　　 (4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。 
　　 (5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。 
　　　　总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三 
　　　　个层次上同时下功夫。