zoukankan      html  css  js  c++  java
  • 数据库设计三范式

    1.范式说明

    1.1 第一范式(1NF)无重复的列

      所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能同时有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行只包含一个实例的信息。简而言之,第一范式就是无重复的列。

      在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。在当前的任何关系数据库管理系统(DBMS)中,不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。

    举例1:

    比如某些数据库系统中需要用到“地址”这个属性,本来直接将“地址”属性设计成一个数据库表的字段就行。但是如果系统经常会访问“地址”属性中的“城市”部分,那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储,这样在对地址中某一部分操作的时候将非常方便。这样设计才算满足了数据库的第一范式,如下表所示。

     UserInfo(ID,Name,Age,LinkTel,Province,City,Address)

    上表所示的用户信息遵循了第一范式的要求,这样在对用户使用城市进行分类的时候就非常方便,也提高了数据库的性能。

     

    1.2 第二范式(2NF)属性完全依赖于主键 [ 消除部分子函数依赖 ]

      第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。例如员工信息表中加上了员工编号(emp_id)列,因为每个员工的员工编号是唯一的,因此每个员工可以被唯一区分。这个唯一属性列被称为主关键字或主键、主码。

      第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。简而言之,第二范式就是属性完全依赖于主键。

      这里说的主关键字可能不只有一个,有些情况下是存在联合主键的,就是主键有多个属性。

    举例2:

    以学生选课为例,每个学生都可以选课,并且有这一门课程的成绩,那么如果将这些信息都放在一张表

    StuGrade(stuNo,stuName,age,sex,courseNo,courseName,credit,score)。

    如果不仔细看,我们会以为这张表的主键是stuNo,但是当我们看到最后一个score属性以后,在想想如果没有课程信息,那么哪里有学生成绩信息呢。

    所以这张表的主键是一个联合主键(stuNo,corseNo),这个联合属性能够唯一确定score属性。

    那么再看其他信息,比如stuName只需要stuNo就能够唯一确定,courseName只需要courseNo就能够唯一确定,因此这样就存在了部分依赖,不符合第二范式。

    如果要让学生课程成绩信息满足第二范式,那么久需要将这张表拆分成多张表,

    一张学生表Studnet(stuNo,stuName,age,sex)

    一张课程表Course(courseNo,courseName,credit)

    还有一张学生课程成绩表StuGrade(stuNo,courseNo,score)

    这样就符合第二范式了。

    1.3 第三范式(3NF)属性不依赖于其它非主属性 [ 消除传递依赖 ]

      满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息

    举例3:

    每一个员工都有一个所属部门,假如有一个员工信息表

    Employee(emp_id,emp_name,emp_age,dept_id,dept_name,dept_info)。

    这张员工信息表的主键是emp_id,因为这个属性能够唯一确定其他所有属性,比如知道员工编号emp_id以后,肯定能够知道员工姓名,所属部门编号,部门名称和部门介绍。所以这里dept_id不是主属性,而是非主属性。但是,我们又可以发现dept_name,dept_info这两个属性也可以由dept_id这个非主属性决定,即dept_name依赖dept_id,而dept_id依赖emp_id,这样就存在了传递依赖。而且我们可以看出传递依赖的一个明显缺点就是数据冗余非常严重。

      那么如何解决传递依赖问题,其实非常简单,我们只需要将dept_name,dept_info这连个属性删除就可以了,

    即:

    Employee(emp_id,emp_name,emp_age,dept_id)

    然后再创建一个部门表Dept(dept_id,dept_name,dept_info)

    这样如果要搜索某一个员工的部门信息dept_info,可以通过数据库连接来实现,查询语句如下:

    select e.emp_id,e.emp_name,d.dept_name from Employee e,Dept d where e.dept_id=d.dept_id

    注意点:

    1. 数据库连接会带来一部分的性能损失
    2. 并不是数据库范式越高越好
    3. 有时会在数据冗余与范式之间做出权衡,在实际的数据库开发过程中,往往会允许一部分的数据冗余来减少数据库连接。
  • 相关阅读:
    CRM SFA Determine the Type of Claim Rule Template to Use
    Log4j 打印堆栈信息
    树查找 二分法
    CRM 公海 领取规则 策略
    【设计模式】策略模式与状态模式
    Alibaba crm
    CRM easy rule & Resource Duplicate Detection
    CRM 线索分配
    SAAS CRM SFA 线索 分配
    SOFA & COLA 企业应用框架 & 代码精进
  • 原文地址:https://www.cnblogs.com/yuan-jun/p/6600524.html
Copyright © 2011-2022 走看看