当前位置:   article > 正文

第8章 数据库规范化设计_逻辑结构设计,数据库规范化问题

逻辑结构设计,数据库规范化问题

在本章中需要了解数据库涉及的步骤,掌握如何绘制数据库的E-R图。掌握如何绘制数据库的模型图,能够使用三大范试实现数据库设计规范化,本章需要完成指定数据库的设计。

8.1 规范化数据库设计的重要性

        本章主要介绍为什么需要规范化的数据库设计,以及数据库的设计步骤。在需求分析阶段,需要捕获客户的需求,收集相关的业务数据,了解数据处理过程。在概要设计阶段,需要标识出各种实体、属性以及各种实体之间的关系,绘制出数据库的E-R图,并与客户交流和沟通,反复进行修改和确认。在详细设计阶段,需要进行数据库的逻辑设计,将E-R图转换为表,并应用三大范式进行审核,使数据库的设计规范化。
        也许有的读者会问,在前几章的项目开发和技能训练中,我们根据业务需求,可直接创建数据库,创建表和插入测试数据,然后查询数据。为什么现在要强调先设计数据库、创建表呢?原因非常简单,正如建造建筑物一样,如果盖一间茅屋或者一间简易平房,会有人花钱请人设计房屋图样吗,毫无疑问,没人请。但是,如果房地产开发商开发一个楼盘,修建多幢楼的居住小区,会情人设计施工图吗,答案是肯定的,不但开发商会考虑设计施工图样,甚至购房者都会观看设计图样。
        同样地道理,在实际的项目开发中,如果系统的数据存储量较大,设计的表比较多,表与表之间的关系比较复杂,首先就需要进行规范化的数据库设计,然后进行具体的创建数据库的工作。无论是创建动态网站,还是创建桌面窗口应用程序,数据库设计的重要性不言而喻,如果设计不当,会存在数据操作西昌、修改复杂、数据冗杂等问题,程序性能也会受到影响。通过进行规范化的数据库设计,可以消除不必要的数据冗余,获得合理的数据库结构,提高项目的应用性能。

1 数据库设计的含义

        数据库设计就是将应用中涉及的数据实体以及这些数据实体之间的关系,进行规范化和结构化的过程。
        下图所示为学生信息数据库的结构,该数据库包含学生信息以及成绩信息,下图还显示了学生,年级,课程,成绩四个数据实体之间的关系。

2 数据库设计非常重要

数据库中创建的数据结构的种类,以及在数据实体之间创立的关系是决定数据库系统效率的重要因素。糟糕的数据库设计表现在一下两个方面。
(1)效率低下。
(2)更新和检索数据时会出现很多问题。
良好的数据库设计表现在以下三个方面。
(1)效率高,
(2)便于进一步扩展。
(3)使得应用程序的开发变得更容易。

8.2 数据库设计的步骤

        通过前面的学习,相信大家对项目的开发有了一个整体上的认识,项目开发需要经过需求分析、概要分析、代码编写、运行测试和部署上线几个阶段,下面重点讨论在各个阶段中数据库的设计过程。
        (1)需求分析阶段:分析客户的业务和数据处理需求。
        (2)概要设计阶段:绘制数据库的E-R图,用于在项目团队内部、设计人员和客户之间进行沟通,确认需求信息的正确性和完整性。
        (3)详细设计阶段:将E-R图转换为多张表,进行逻辑设计,确认各表的主、外键,并应用数据库设计的三大范式进行深刻。经项目组开会讨论确定后,还需要根据项目的技术实现、团队开发能力以及项目的成本预算,选择具体的数据库(如MySQL或Oracle等)进行物理实现。
        以上步骤完成后,才进行代码编写阶段开发应用程序。现在讨论在需求分析阶段对后台数据库的分析。
        需求分析阶段的重点是调查、手机并分析客户业务的数据需求、处理需求、安全性与完整性需求。
        常用的需求调研方法包括在客户的公司跟班实习、组织召开调查会、邀请专人介绍、设计调查表并请用户填写与查阅与业务相关的数据记录等。
        常用的需求分析方法包括调查用户的公司组织情况、各部门的业务需求情况、协助用户分析系统的各种业务需求和确定新系统的边界。
        无论数据库的大小和复杂成都如何,在进行数据库的系统分析时,都可以参考以下步骤。

1 收集信息

        创建数据库之前,设计人员必须充分理解数据库需要完成的任务和功能。简单地说,就是需要了解数据库需要存储哪些信息(数据)、实现哪些功能。以酒店管理系统为例,我们需要了解酒店管理系统的具体功能,以及正在后台数据中保存的数据,如以下需求。
        (1)酒店为客人准备充足的客房,后台数据需要存放每间客房的信息,如客人姓名、客房类型、价格等。
        (2)客人在酒店入住需要办理入住手续,后台数据库需要存放客人的信息,如客人姓名,身份证号等。

2 标识实体

        在收集需求信息后,必须标识数据库要管理的关键对象和实体。我们前面曾经学习过对象的概念,实体可以是有形的事物,如人或产品;也可以是无形的实物,如商业交易、公司部门或发薪周期。在系统中标识这些实体之后,与他们相关的实体就会条理清楚。以酒店管理系统为例,需要表示出系统中的主要实体如下所示:
        (1)客房、标准间、三人间、豪华间和总统套房。
        (2)客人:入住酒店客人的个人信息。

数据库中的每个实体都拥有一个与其相对应的表,按照上述酒店管理系统的需求,在酒店管理系统数据库中会对应至少两张表,分别是客房表和客人表。

3 标识每个实体需要存储的详细信息

将数据库中的主要实体标识为表的候选实体以后,就要标识每个实体存储的详细信息,也称为实体的属性。这些属性将组成表中的列。简单来说,就是需要细分出每个实体中包含的子成员信息。下面以酒店管理系统为例,逐步解析每个实体的子成员信息,

客房:客房号、客房类型、客房状态、客房描述、床位数、入住人数、价格。

客人:客人姓名、身份证号、客人编号、入住日期、结账日期、押金、总金额。

在进行实体属性分解时,含义相同的成员信息不能重复出现吗,如联系方式电话等。
每个实体对应一张表,实体中的每个子成员对应表中的一列。例如,从上述的关系可以看出客人应该包含姓名和身份证号等列。

3 标识实体之间的关系

关系数据库有一项非常强大的功能,即他能够关联数据库中的各个项目的向相关信息。不同类型的信息可以单独存储,数据库引擎还可以根据需要将数据组合起来。在数据库设计过程中,要表示实体之间的关系,首先需要分析数据表,确定这些表在逻辑上是如何相关的,然后添加管系列建立起表之间的链接。以酒店管理系统为例,客房与客人有主从关系,我们需要在客人实体中表明其入住的客房号。

上机练习1 标识员工晋级业务的主体
(1)在企业中,每位员工都隶属于企业的一个部门,都有一个对应的岗位。假设每个部门设置多个不同的岗位,每个岗位可以安排多个员工。为了激励员工为企业做出更大的贡献,企业会定期给优秀员工加薪、晋级作为奖励,以提高其工作的积极性,保障员工队伍的稳定性。企业将会保存每位员工每次晋级的记录:
 

员工编号姓名入职日期岗位部门晋级日期
1001Mark2010-12-1部门经理办公室2015-12-30

需要设置部门表:需要设置部门名称、部门编号。
需要设置岗位表:需要设置岗位名称、岗位编号、岗位所属部门。
其中学生表与部门表、岗位表有组从关系,在学生表中标明了员工实体中所属部门和岗位。
岗位表和部门表也是主从关系,岗位表中需要有一列表述岗位所属。

8.3 绘制E-R图

        在需求分析阶段了解了客户的业务和数据处理需求后,就进入了概要设计阶段。我们需要和项目团队的其他成员及客户进行沟通,讨论数据库的设计是都满足了客户的业务和数据处理需求。和机械行业需要机械制图,建筑行业需要施工图一样,数据库设计也许要图形化的表达方式--E-R(Entity-Relationship),也称为实体-关系图。它包含一些具体图形符号。

1 实体-关系模型

实体-关系模型通常使用E-R图的形势来描述。
(1)实体
所谓实体就是指现实世界中具有区分其他事物的特征或属性并与其他事物有联系的事物。例如,酒店管理系统中的客房(如1008客房、1018客房)、客人(如张三、李四、王五等)。
        实体一般是名词,对应表中的一行数据,例如张三用户是一个实体,它对应于客人表中‘张三’这一行的数据,包括客人姓名、身份证号等信息。严格来说,实体指的表中的一行特性数据,但在开发时,也常常成为一个表为一个实体。
(2)属性
属性可以理解为实体的特征。例如,‘客人’这一实体的属性有入住日期、结账日期和交付的押金等,属性对应表中的列。
(3)联系
联系是指两个或多个实体之间的关联关系。

如上图表示为客人实体与客房实体之间的联系,实体一般用矩形表示,一般为名词,属性由椭圆表示,一般也是名词,联系用菱形表示,一般是动词。
(4)映射基数
映射基数表示通过练习与该实体关联的其他实体的个数。对于实体集X和Y之间的二元关系,映射基数必须为以下基数之一。
一对一。X中的一个实体最多与Y中的一个实体关联,并且Y中的一个实体最多与X中的一个实体关联。假定每辆汽车在同一时刻只能占用一个车位,同一时刻每个车位也只能停放一辆车,那么汽车实体和车位实体之间就是一对一的关系。一对一的关系表示为1:1.
一对多:X中的一个实体可以与Y众任意数量的实体进行关联,Y中的一个实体最多与X中的一个实体进行关联,例如:一个客房可以入住多位客人,一位客人只能入住一个客户,一位客人只能入住一个客房,所以,客房实体和客人之间就是典型的一对多关系。一对多关系表示为1:N。
多对一:X中的一个实体最多与Y中的一个实体关联,Y中的一个实体可以与X中任意数量的实体关联。客房与客人实体之间就是典型的一对多关系,反过来说,客人实体与客房实体之间就是多对一的关系,多对一表示为N:1
多对多:X中的一个实体可以与Y中的任意数量的实体关联,反之亦然。例如,图书馆的每本图书可以借给多个读者,每个读者可以借阅多本书,那么,图书实体和读者实体之间就是典型的多对多关系。可以表示为M:N。
(5)实体关系图
E-R图以图形的方式将整个数据库的整体结构表示出来,E-R图由以下几部分组成。
1 矩形表示实体集
2 椭圆表示属性。
3 菱形表示联系集
4 直线用来连接属性和实体集,也用来连接实体集和联系集。
在E-R图中,直线是可以有向的(在末端有一个箭头),用来表示联系集的映射基数,
上图表示可以通过联系与一个实体相关联的其他实体的个数,箭头的定位很简单,可以将其视为指向引用的实体。
1:1 每个客户最多有一个账户,并且每个账户最多归一个客户所有。
1:N 每个客户可以有任意数量的账户,但每个账户最多归一个账户所有
M:N,每个账户可以有任意数量的客户,每个账户归任意数量的客户所有。
根据E-R图的各种符号,可以绘制酒店管理系统的E-R图
绘制E-R图后,还需要反复与客户进行沟通,让客户提出修改意见,以确认系统中的数据处理需求是否正确完整。

2关系型数据库模式

用二维表的形式表示实体与实体之间联系的数据模型称为关系模型。关系数据库模式是对关系数据库结构的描述,或者是对关系数据库框架的描述。一个关系通常对应一张表。一般来说,把关系模式表示为如下形式。
R(U)或者R(A,B)
其中,R表示关系名,U表示属性集合,A、B代表U中的属性,将E-R图转换为关系模式如下。
(1)把每个实体都转化为关系模式R(A,B)形式。
以酒店管理系统为例,实体客人和客房可以分别使用关系模式表示如下。
1 客房(客房号,客房描述,客房类型,客房状态,床位数,入住人数,价格)
2 客人(客人编号,客人姓名,身份证号,入住日期,结账日期,押金,总金额)
(2)建立实体间联系的转换
实体间联系氛围一对一,一对多,多对多三种,当两个实体各自转化为关系模式后,实体键联系的转换如下。
1 一对一的转换:把任意实体的主键放到另一个实体的关系模式中。
2 一对多的转换:把联系数量为1的实体的主键放到联系数量为N的实体关系模式中。
3 多对多得转换:把两个主题中的主键和联系的属性放在另一个关系模式中,注意多生成一个关系模式。

8.4 绘制数据库模型图

在概要设计阶段,了解了客户的需求,并绘制了E-R图。在后续的详细设计阶段,我们需要把E-R图转化为数据库中的多个表,并表示各表的主键和外键。本节将介绍如何把E-R图转化为数据库模型图,审核各表的结构是否规范将在8.5节中讲解。
        设计良好的数据库模型可以通过图形化的方式显示数据库存储的信息及表之间的关系,以确保数据库设计准确、完整且有效。
        下面以酒店业务实体为素材,演示如何在Microsoft Visio中将实体以及实体间的关系转化为数据库模型图,下面详细介绍启动软件之后的操作步骤

1 绘制数据库模型图

(1)新建数据库模型图
文件->新建->数据库->数据库模型图命令,将出现一个空白页面,可以看到绘图页面,将出现一个空白页面,可以看到绘图页面左侧是绘图工具,其中包含很多实体关系图。
(2)添加实体
在绘图窗口左侧关系中选择实体并将其拖动到页面适当地位置,在数据库属性中定义数据表的物理名称及概念名称。
(3)添加数据以及相应的属性
在数据库属性中选择类别为列,添加物理名称、数据类型和注释等
物理名称:表示列名,一般输入英文,如GuestId.
数据类型:表示列名的类型,如整数为INTERGER类型。
必须的:表示是否可以为空。
PK:表示主键
注释:关于该列名的说明。
(4)添加实体之间的映射关系
添加实体之间的映射关系的具体步骤如下。
与添加‘客人’实体GuestRecord的步骤一样添加‘客房实体’ROOM。
为GuestRecord添加外键约束列RoomId(客房号),对应Room表中的RoomId项。
        单击实体关系中的连接线工具,将连接线工具放到Room表的中心,使得表的四周出现方框,按住鼠标左边将连接线工具拖动到GuestId表的中心,当GuestId表四周出现方框时,松开鼠标左键,此时,两个连接点均变成红色,同时将Room表中的主键RoomId作为外键添加到子表GuestRecord中,会默认为子表。

2 E-R图转化为数据库模型图的步骤
(1)将E-R图中各实体转化为对应的表,将个属性转化为各表对行的列。
(2)标识每个表的主键列,需要注意的是,要为没有主键的表添加ID编号列。该列没有实际含义,只用作主键或者外键,如客人表中的GuestId列,客房表中的RoomId列,为了数据编码的兼容性,建议使用英文字段。为了直观起见,在英文括号内注明对应的中文含义。
(3)在数据库模型中体现实体之间的映射关系。客房和客人之间是一对多的关系,对应一对多关系的两个实体,一般会各自转换为一张表,并且后者对应的表引用前者对应的表,即客人(GuestRecord)表中的客房号来自客房(Room)表中的客房号,他们之间应建立主键、外键关系。一般来说,一般来说,一对多关系是一个表中的主键对应另一个表中的可重复字段,主键的值是不能重复的,而关联的字段是可以重复的,就会存在一个值对应一个值或者一个值对应多个值两种可能,即一对多,在一对一关系中,一般是一个主键对应一个不可重复的字段,显然只有一个值对应一个值的可能。
        多对多映射关系也是比较常见的,如课程和学生实体就是多对多关系,要表示多对多关系,除了将多对多关系中的两个实体各自转化为表之外,一般还会创建第三个表,称为连接表,他将多对多关系划分为两个一对多关系。将这两个表的主键都插入第三个表中。因此,第三个表用来记录关系的每个匹配项或势力。例如,订单表和产品表是多对多的关系,这种关系通过与‘订单明细表建立两个一对多的关系来定义。一个订单可以有多个产品,每个产品可以出现在多个订单中。关于这一点可以在第9张的数据库设计实例中慢慢理解。

上机练习2 绘制员工晋级业务的数据库模型图,标识员工晋级业务实体、实体属性以及实体之间的关系

8.1 设计规范化

1 设计问题

        在概要设计阶段,同一个项目,10个设计人员可能设计出10种不同的E-R图。不同的人从不同的角度,标识不同的实体,实体又包含不同的属性,自然就设计出了不同的E-R图。那么怎样审核这些设计图呢,怎样评审处最优秀的设计方案呢,下一步就是规范化E-R图。
        为了讨论方便,下面以上面例子中某酒店客人住宿信息表为例来介绍,该表保存了酒店提供的了人住宿信息。
 

客人编号姓名地址...客房号客房描述客房类型客房状态床位数价格入住人数
C1001张三Addr1...1001A幢1层单人间入住1128.01

从用户的角度而言,将所有信息放在一个表中很方便,因为这样查询数据库比较容易,但上表存在以下问题。
       (1)信息重复
表中‘客房类型’,‘客房状态’和‘床位数’列中有许多重复的信息,如标准间、入住等。信息重复会造成存储空间的浪费及一些其他问题,如果不小心输入标准间和标间或总统套房和总统房,则在数据库终将被当成两种不同的客房类型。
(2)更新异常
冗余信息不仅浪费存储空间,还会增加更新的难度,如果需要讲客房类型修改为标间而不是标准间,则需要修改所有包含该值的行。如果由于某种原因没有更新所有行,则数据库中会存在两种客房类型,即一个标准间,另一个是标间,这种行为成为更新异常。
(3)插入异常(无法表示某些信息)
从表8-2中我们会发现可能会存在客房类型都是标准件,但是价格不同的情况,这样就造成了同一个酒店相同类型的客房价格不同。这种问题称为插入异常。
(4)删除异常(丢失有用的信息)
在某些情况下删除一行数据,可能会丢失有用的信息。例如,如果删除客房号为‘1001’的行,就会丢失客房类型为单人间的账户的信息,该表只剩下标准间和总统套房两种客房类型。当希望查询有哪些客房类型时,将会误认为只有标准间和总统套房两种客房类型,这种情况成为删除异常。

2 规范设计

如何重新规范设计表来避免上述诸多问题呢。
在进行数据库设计时,有一些专门的规则,称为数据库的设计范式。遵守这些规则,将创建设计良好的数据库。下面将逐一讲解数据库设计中著名的三大范式理论。
(1)第一范式
第一范式(First Normal Form,1NF)的目标是确保每列的原子性。如果每列(或者说每个属性值)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式例如:
客人住宿信息表(姓名,客人编号,地址,客房号,客房描述,客房类型,客房状态,床位数,入住人数,价格)。
        其中,地址列可以细分为国家,省,市,区等,甚至更多程序把‘姓名’列拆分为‘姓’和‘名’。如果业务需求中不需要拆分地址列,则该表已经符合第一范式,如果需要将‘地址’列拆分,则符合第一范式的表如下:
客人住宿信息表(姓名,客人编号,国家,省,市,区,门牌号,客房号,客房描述,客房类型,客房状态,床位数,入住人数,价格等)。
(2)第二范式
第二范式在第一范式的基础上更近一层,其目标是确保表中的每列都和逐渐相关。如果一个关系满足第一范式,并且除了逐渐意外的其他列都依赖于该逐渐,则满足第二范式。
        客人住宿信息表数据主要用来描述客人住宿信息,所以该表主键位(客人编号,客房号)。
(1)姓名列、地址列->客人编号列。
(2)客房描述列、客房类型列、客房状态列、床位数列、入住人数列、价格列->客房号列。
        其中->表示依赖,以上各列没有全部依赖于逐渐(客人编号,客房号),只是部分依赖于主键,违背了第二范式的规定。所以在使用第二范式的原则对客人住宿信息表进行规范化之后分解为一下两个表。
(1)客人信息表(客人编号,姓名,地址,客房号,入住时间,结账日期,押金,总金额等),主键为客人编号,其他列全部依赖于主键列。
(2)客房信息表(客房号,客房描述,客房类型,客房状态,床位数,入住人数,价格等),主键为‘客房号’,其他列全部依赖于主键列,也就是全部被他所代表。
(3)第三范式在第二范式的基础上更近一层,第三范式的目标是确保每列都和主键列直接相关,而不是间接相关。如果一个关系满足第二范式,并且除了主键以外的其他列都只依赖于主键列,列和列之间不存在相互依赖关系,则满足第三范式。
        为了理解三范式,需要根据Armstrong公里(从一致的一些函数依赖可以推导出另外一些函数依赖)来定义传递依赖。假设A,B和C是关系R的三个属性,如果A->B(A依赖于B)且B->C,则从这些函数依赖中,可以得出A->C.如上所述,依赖A->C称为依赖传递。
        以第二范式中的客房信息表为例,初看该表时没有问题,满足第二范式,每列都和主键客房号相关,再细看会发现:
1床位数列、价格列->客房类型列;
2 客房类型列->客房号列。
3床位数列、价格列->客房号列。
为了满足第三范式,应该去掉‘床位数’列,价格列和客房类型列,将客房信息表分解为以下两个表。
(1)客房表(客房号,客房描述,客房类型编号,客房状态,入住人数)
(2)客房类型表(客房类型编号,客房类型名称,价格等)
又因为第三范式也是对字段冗余性的约束,即任何字段都不能由其他字段派生出来,所以要求字段没有荣誉。如何正确认识冗余呢。
        主键与外建在多表中的重复出现不属于数据冗余,非建字段的重复出现才是数据冗余。在客房表中‘客房状态’存在冗余,非健字段的重复出现才是数据冗余。在客房表中‘客房状态’存在冗余,需要进行规范化,规范化以后得表如下
(1)客房表(客房号,客房描述,客房类型编号,客房状态编号,入住人数等)
(2)客房状态表(客房状态编号,客房状态名称)

3审核客房实体

了解了用于规范化数据库设计的三大范式后,下面我们一起来审核上表的客房实体。
(1)是否满足第一范式
第一范式要求每列必须是最小的原子单元,即不能再细分。前面我们曾提及,为了方便查询,地址需要氛围省、市、区、市等,但目前还没有这方面的查询需求,因此本例已经满足第一范式。
(2)是否满足第二范式
第二范式要求每列必须和主键相关,不相关的列放入别的表中,既要求一个表只能描述一件事情。
实用的技巧:可以直接查看该表描述了那几件事情,然后一件事情创建了一个表,观察该表描述了那几件事情,该表描述了两件事情:客人信息和客房信息,我们需要将其拆分成两个表,对各列进行筛选拆分后分为两个表:
,其中客人编号和客房号分别为这两个表的主键:

客人信息表
 

客人编号姓名地址...
C1001姓名地址

客房信息表
 

客房号客房描述客房类型客房状态床位数价格入住人数
1001A东一层单人间入住11281

上图还在展示了符合第二范式的酒店业务E-R图。
(3)是否满足第三范式
第三范式要求表中各列必须与主键朱姐相关,不能间接相关,即需要拆分客房信息表为客房表、客房类型表和客房状态表
客房表
 

客房号客房描述客房类型编号客房状态入住人数
1001A幢1层001客房状态入住人数

客房类型表
 

客房类型编号客房类型名称床位数价格
001单人间1128

客房状态表

客房状态编号客房状态名称
001客房状态名称

按照第三范式的要求,我们在符合第二范式的酒店业务E-R图基础上继续规范数据表结构,如下所示:
4 规范化和性能关系

需要提醒的是,对于项目的最终用户来说,客户最关系的是方便、清晰的数据结果。在设计数据库时,设计人员和客户对数据库的设计规范化存在一定的矛盾。前面我们通过三大范式分解出三个表,为了满足客户的需求,最终需要通过三个表之间的连接查询,获取客户需要的数据结果,插入数据同样如此,对于客户输入的数据,我们需要分开插入三个不同的表中。
        由此可以看出,为了满足三大范式,数据操作新能会受到相应的影响。所以在实际的数据库设计中,既要考虑三大范式,避免数据的冗余和各种数据操作异常,又要考虑数据访问性能。有时为了考虑性能允许适当地数据冗余。例如,有一个存放商品信息,其数据结构如下:
 

商品名称商品型号单价数量金额
电视机29寸25004010000

表中的金额列的存在表明该表的设计不满足第三范式,因为金额可以有单价乘以数量得到,所以说明金额是冗余列。与第三范式中介绍的冗余相比,前面介绍的冗余属于低级冗余,我们反对低级冗余。不要轻易违反数据库的规范化原则,如果处理怒号。可能会适得其反。

提示:如何进行范式设计
(1)向表中插入数据,查看表中的每个属性是否存在重复、插入异常、更新异常和删除异常。
(2)对照三大范式的定义,解决表中的异常问题。
(3)第一范式的目标是确保每列都是不可再分的最小数据单元,查看每列是否都满足第一范式。
(4)第二范式要求每列与主键相关,不相关的列放入彼得表中,即要求一个表只描述一件事情。
(5)第三范式要求表中各列必须与主键直接相关,不能间接相关,查看各表是否满足三大范式。
本章小结
1 在需求分析阶段,设计数据库的一般步骤如下。
(1)收集信息
(2)标识实体
(3)标识每个实体的属性。
(4)标识实体之间的关系。
2 在概要设计阶段和详细设计阶段,设计数据库的一般步骤如下
(1)绘制E-R图
(2)将E-R图转化为数据库模型图。
(3)应用三大范式规范化表设计。
从关系数据库表中出去冗余数据的过程成为规范化。如果使用的当,规范化是获得高效的关系数据库表的逻辑结构最好、最容易的方法。规范化数据库设计时,应该执行下列操作。
(4)将数据库表中除去冗余数据的过程称为规范化。如果使用得当,规范化是获得高效的关系数据表的逻辑结构最好的最容易的方法。规范化数据库设计时。
(5)从表中删除荣誉的列。
(6)标识所有依赖于其他数据项的数据。
3.三大范式要求如下:
第一范式:其目标是确保每列的原子性。
第二范式:在第一范式的基础上更近一层,其目标是确保表中的每列都和主键相关。
第三范式:在第二范式的基础上更近一层,其目标是确保每列都和主键列直接相关,而不是间接相关。

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/article/detail/41499
推荐阅读
相关标签
  

闽ICP备14008679号