第二篇 数据库基础篇
第3章 熟悉数据库
数据库从字面的意思上理解它就是一个存储数据库的仓库,就像用来存储药品的药库或用来存放粮食的粮库一样。要使用数据库就要先对数据库有一个了解。本章主要学习以下知识点:
❑ 数据库的历史和模型
❑ 数据库的三级模式和二级映像
❑ 关系型数据库的设计
❑ 实体-联系图的绘制
本章内容基本涵盖了关系型数据库的设计和实体-联系图的绘制以及数据库的基本知识。通过本章的学习,读者可以了解数据库的历史,掌握关系型数据库的设计方法以及实体-联系图的绘制。
3.1 什么是数据库
随着计算机和网络的普及,我们日常的工作和学习都离不开数据库了,如果没有数据库,我们就不能在网上订书,网上也就没有我们浏览的网站了。那么什么是数据库呢?本节就将讲解数据库的历史、数据库的模型、数据库的三级模式和二级映像、数据库相关的术语以及数据库设计的完整性。
3.1.1 了解数据管理的历史
任何事物的发展都有一段历史,数据管理的发展也不例外。在数据管理的发展过程中,主要经历了3个阶段,即人工管理阶段、文件系统阶段、数据库系统阶段。
1. 人工管理阶段
20世纪50年代中期以前是人工管理阶段,世界上第一台计算机(ENIAC)是1946年2月14日在美国诞生的。那时计算机还是一个陌生的词汇,对于计算机来说,存储信息的设备没有磁盘,只有磁带、卡片等存储设备;计算机中也没有操作系统更没有管理软件;处理数据的方式只有批处理方式。在人工管理阶段,主要负责数据管理的是人。人工管理数据具有以下4个特点:
1)不能长期保存数据。在20世纪50年代中期之前,计算机一般在信息中心这样的研究机构里才能拥有,当时由于存储的设备有限,都是在做实验的时候暂存实验数据,做完实验就把结果打在纸带或者磁带上带走,所以数据一般不需要长期保存。
2)数据并不是由应用软件管理的而是由应用程序自己管理的。作为程序员在编写程序时既要设计程序逻辑结构又要设计物理结构以及数据的存取方式等,因此,对程序员编写代码的工作量和质量要求都很高。
3)数据不能共享。在人工管理阶段,可以说数据是面向程序的,由于每一个应用程序都是独立的,即使要使用的相同数据已经在其他应用程序中存在,在应用程序之间也是不能共享的,这样也造成了大量的数据冗余。
4)数据不具有独立性。应用程序中只要发生改变,数据的逻辑结构和物理结构就相应地发生变化。因而程序员都要做出相应的修改,给程序员的工作带来很多的负担。
图3.1 人工管理阶段管理数据
根据人工管理阶段管理数据的特点,如果计算机中有3个应用程序,那么它们和各自数据集之间的对应关系就如图3.1所示。
2. 文件系统阶段
20世纪50年代后期到60年代中期,计算机开始应用于数据管理方面。此时,计算机的存储设备也不再是磁带和卡片了,已经可以用磁盘直接存储了。此时,存储数据使用的是文件系统也称为管理软件,文件系统是操作系统中负责管理和存储文件信息的软件机构。文件系统由三部分组成:与文件管理有关的软件、被管理的文件以及实施文件管理所需的数据结构。文件系统阶段存储数据就是以文件的形式来存储,由操作系统统一处理。文件系统阶段也是数据库发展的初级阶段,使用文件系统存储数据具有以下四个特点:
1)可以长期保存数据。有了大容量的磁盘作为存储设备,计算机开始被用来处理大量的数据并可以存储数据。
2)有简单的数据管理功能。文件的逻辑结构与物理结构脱钩,程序和数据分离,使数据与程序有了一定的独立性,减少了程序员的工作量。
3)共享数据能力差。由于每一个文件都是独立的,当需要用到相同的数据时,必须建立各自的文件,数据还是无法共享,也会造成大量的数据冗余。
4)数据不具有独立性。在此阶段数据仍然不具有独立性,当数据的结构发生改变时,也必须修改应用程序,修改文件的结构定义;而应用程序的改变也将改变数据的结构。
图3.2 文件系统阶段管理数据
根据文件系统阶段管理数据的特点,如果计算机中有3个应用程序,那么它们和各自文件之间的对应关系就如图3.2所示。
说明
从系统角度来看,文件系统是对文件存储器空间进行组织和分配,负责文件的存储并对存入的文件进行保护和检索的系统。具体地说,它负责为用户建立文件,存入、读出、修改、转储文件,控制文件的存取,当用户不再使用时撤销文件等。
3. 数据库系统阶段
从20世纪60年代后期开始就进入了数据库系统阶段。随着计算机的普及,同时计算机的外存设备磁盘的容量也得到了扩充,需要管理的数据也与日俱增,此时,在文件系统的基础上就开始有了数据库技术。最早的数据库管理系统是在1961年由通用电气公司开发的,此后,数据库的技术得到了飞速的发展。数据库存储数据不仅存储数据的本身同时也存储数据之间的联系。在数据库系统阶段管理数据具有以下4个特点:
1)实现数据的共享。进入数据库系统阶段之后,数据终于可以得到共享。也就是说,数据在存入数据库后,想使用数据的用户可以同时来访问数据库使用数据,这样就减少了数据的冗余。
2)数据具有了独立性。在数据库中数据库的逻辑结构和应用程序之间是相互独立的,同时数据库的物理结构变化也不会影响数据库的逻辑结构,这就给程序员减少了很多的工作量。
3)数据实现集中控制。此时,数据不再由各自的应用程序管理,而是由数据库管理系统统一管理,这样可以保证数据的安全性和可维护性。
4)故障恢复。在没有数据库管理系统之前,如果数据出现丢失或损坏的情况,那么数据是无法恢复的;但是有了数据库之后,数据库管理系统的备份恢复机制就可以帮助用户找回丢失和损坏的数据,可以最大限度地减少损失。
根据数据库系统阶段管理数据的特点,如果计算机中有3个应用程序,那么它们与数据库之间的对应关系就如图3.3所示。
图3.3 数据库系统阶段管理数据
从文件系统发展到数据库系统,这在信息领域中具有里程碑的意义。在文件系统阶段,人们在信息处理中关注的中心问题是系统功能的设计,因此程序设计占主导地位;而在数据库方式下,数据开始占据了中心位置,数据的结构设计成为信息系统首要关心的问题,而应用程序则以既定的结构为基础进行设计。
3.1.2 数据库的模型
数据库的模型从数据库技术出现至今一共有3种比较通用的模型,目前使用最多的是关系型数据模型。下面就分别介绍这3种模型。
1. 层次结构模型
最早使用层次结构模型的是IBM公司的IMS(Information Management System),即数据库管理信息系统,这个系统也是被广泛应用的。层次结构模型类似于倒置的树型,一个父表可以有多个子表,但是每一个子表都对应着一个父表。图3.4所示就是一个学校人员的层次结构模型。
图3.4 学校人员层次结构模型
在图3.4中学校可以看做是父表,在学校下面有教职员工和学生两个子表,教职员工下面又有两个子表,学生下面也有两个子表,但是每一个子表都只有一个父表与之对应。
由于层次结构模型的结构很难改变,而且在表示表之间的关系时也有一些局限性,所以目前使用层次结构模型设计数据库是比较少的。
2. 网状结构模型
网状结构模型是对层次结构模型的改进,使用网状结构模型的代表是DBTG(Data Base Task Group),它是20世纪70年代数据系统语言研究会下属的数据库任务组提出的一个系统方案。网状结构模型打破了层次结构模型使用的限制,可以更全面地描述数据库中表之间的关系,可以一个父表没有子表,也可以一个子表有多个父表,还可以设置两个表之间的多种关系。图3.5所示是一个网状结构模型的例子。
图3.5 技术部门网状结构模型
图3.5中描述的是某软件公司技术部门的组成结构,这里程序员拥有员工宿舍和开发大厅两个父节点,这是层次结构模型不能描述的。尽管网状结构模型已经在层次结构模型的基础上有了一定的改进,但是对数据库的设计者要求很高,必须要非常熟悉数据库才能使用这种网状结构模型。
3. 关系结构模型
关系结构模型可以说是在层次结构模型和网状结构模型的基础上发展而来的,是目前使用最多的数据模型。最早给关系结构模型下定义的是E.F.Codd博士,他说:“关系数据结构保护数据,并且允许以一种可以预测并防止差错的方法操作数据。”关系结构模型实际上就是一个二维表,是由行和列组成的。例如,一个员工信息登记表就是一个二维表即关系模型,如表3.1所示。
表3.1 员工信息登记表
在表3.1中,把一行数据称为一个元组,其中一共就有3个元组;把一列数据称为一个字段或属性,其中一共就有6个属性,即员工编号、姓名、年龄、性别、所在部门、联系方式。要想在设计数据库时使用关系结构模型,必须要做到规范化。关于规范化的问题将在3.2节中详细讲述。
目前大多数的数据库都是属于关系型数据库,这些数据库主要有IBM DB2、Oracle、SQL Server、MySQL、SyBase、Informix、Access、FoxPro等。
说明
关系数据库的产生是在1970年,IBM的研究员E.F.Codd博士在刊物Communication of the ACM上发表了一篇名为“A Relational Model of Data for Large Shared Data Banks”的论文,提出了关系模型的概念,奠定了关系模型的理论基础。
3.1.3 学习数据库的三级模式和二级映像
数据库的模式(Schema)是对现实世界的抽象,是对数据库中全体数据的逻辑结构和特征的描述。模式反映的是数据的结构及其联系,数据库系统在其内部具有三级模式和二级映像。三级模式分别为外模式、模式与内模式,二级映像则是外模式/模式映像和模式/内模式映像。
1. 三级模式
美国国家标准学会(American National Standard Institute,ANSI)的数据库管理系统研究小组于1978年提出了标准化的建议,将数据库结构分为3级:面向用户或应用程序员的用户级、面向建立和维护数据库人员的概念级、面向系统程序员的物理级。用户级对应外模式,概念级对应模式,物理级对应内模式。以下就分别讲解这3种模式。
(1)模式
模式对应着概念级,它是由数据库设计者综合所有用户的数据,按照统一的观点构造的全局逻辑结构,是对数据库中全部数据的逻辑结构和特征的总体描述,是所有用户的公共数据视图。它是由数据库管理系统提供的数据模式描述语言(Data Description Language,DDL)来描述、定义的,体现并反映了数据库系统的整体观。
(2)外模式
外模式对应于用户级,它是某个或某几个用户所看到的数据库的数据视图,是与某一应用有关的数据逻辑的表示。外模式是从模式导出的一个子集,包含模式中允许特定用户使用的那部分数据。用户可以通过外模式描述语言来描述、定义对应于用户的数据记录(外模式),也可以利用数据操纵语言(Data Manipulation Language,DML)对这些数据记录进行操作。
说明
DML语言可以对数据进行4种操作,即创建(Create)、读取(Read)、更新(Update)和删除(Delete),也把它说成是对数据执行CRUD操作。DDL语言是用于描述数据库中要存储的现实世界实体的语言,主要包括DROP、CREATE、ALTER、GRANT、REVOKE、TRUNCATE等操作,这在后面的章节中会详细介绍。
(3)内模式
内模式对应于物理级,它是数据库中全体数据的内部表示或底层描述,是数据库最低一级的逻辑描述,它描述了数据在存储介质上存储方式的物理结构,对应着实际存储在外存储介质上的数据库。
2. 二级映像
数据库系统的三级模式是对数据的3个抽象级别,它把数据的具体组织留给DBMS管理,使用户能逻辑地、抽象地处理数据,而不必关心数据在计算机中的具体表示与存储。为了能够在内部实现这3个抽象层次的联系和转换,DBMS在这3个级别之间提供了两层映像:外模式/模式映像和模式/内模式映像。
外模式/模式映像使数据具有较高的逻辑独立性。它定义了该外模式与模式之间的对应关系。这些映像定义通常包含在各自外模式的描述中。当模式改变时,DBA要对相关的外模式/模式映像做相应的改变,以使外模式保持不变。应用程序是依据数据的外模式编写的,外模式不变应用程序就没必要修改。所以,外模式/模式映像功能保证了数据与程序的逻辑独立性。
模式/内模式映像使数据具有较高的物理独立性。它定义了数据库全局逻辑结构与存储结构之间的对应关系。该映像定义通常包含在模式描述中。当数据库的存储结束了,DBA要对模式/内模式映像做相应的改变,以使模式保持不变。模式不变,与模式没有直接联系的应用程序也不会改变。所以,模式/内模式映像功能保证了数据与程序的物理独立性。
3.1.4 数据库中的相关术语
在Oracle 11g数据库中每个数据库里面都包含很多对象,主要包括表、视图、存储过程、触发器以及约束。在本小节里只简单介绍一下每一个术语的含义,在后面的章节中会详细地讲解这些术语的使用。
1. 表
表,即在数据库中存放数据用的数据表。每一个数据库中都可以包含多张数据表,但是每一个数据表的名字都是不能重复的。表的一行代表一条记录,每一列都有一个列名,列名是唯一的,行与列的交叉点称为字段。例如,创建一个存放图书信息的表,表中信息包括图书编号、图书名称、图书作者、图书出版社、图书价格、备注,如表3.2所示。
表3.2 图书信息表
在表3.2中,第一行是表中每一列的列名,后两行每一行都是表中的一条记录。
2. 视图
视图是数据库中的虚拟表。在视图中存放的是从数据库表中查询出来的记录,使用视图主要是为了方便信息查询,同时也能够缩短查询数据的时间。
3. 存储过程
存储过程是由SQL语句和控制流语句组成的语句块。存储过程存储在数据库内,可由应用程序通过存储过程的名称调用执行。
存储过程在开发软件时,可以把大量的数据操作放在服务器端的存储过程中,而只返回需要的数据,这样就减少了数据的传输量,速度也可以大大地提高。
4. 触发器
触发器是特殊的存储过程,也是由SQL语句和程序控制语句组成的。但是,触发器在数据库中是不需调用而自动执行的。例如,在触发器中可以定义在修改某张表记录后执行触发器中的内容。
5. 约束
约束是在数据库中保证数据库里表中数据完整性的手段。在Oracle 11g中使用的约束有主键约束、外键约束、唯一约束、检查约束、非空约束5个,其中主键约束和唯一约束都被认为是唯一约束,而外键约束被认为是参照约束。
(1)主键(Primary Key)约束
主键约束在每个数据表中只能有一个,但是一个主键约束可以由多个列组成,通常把由多个列组成的主键又叫做复合主键或组合主键。主键约束可以保证主键列的数据没有重复值且值不为空,也可以说是唯一地标识表中的一条记录。
(2)外键(Foreign Key)约束
外键约束之所以被认为是参照约束,是因为它主要用作把一个表中的数据和另一个表中的数据进行关联,表和表之间的关联是为了保证数据库中数据的完整性,使用外键保证数据的完整性,也叫参照完整性。在3.1.5小节还会详细地说明数据的完整性。下面就创建商品信息表和商品类型信息表,并建立两个表之间的外键约束,如表3.3所示。
表3.3 商品信息表和商品类型信息表
在商品信息表中“商品编号”是主键,而在商品类型信息表中“类型编号”是主键,当把商品信息表中的“商品编号”与商品类型信息表中的“类型编号”设置为外键约束后,在商品信息表中的类型信息就可以用商品类型信息表中的类型编号代替。设置完外键约束后,商品信息表中类型字段值必须是在商品类型信息表中存在的,同时当在商品类型信息表中删除一个类型时,如果商品信息表已经使用过该类型,那么商品类型信息表中的数据就无法被删除。这样就保证了数据库中数据的完整性。
(3)唯一(unique)约束
唯一约束和主键约束一样都是设置表中的列不能重复的约束,区别就是一个表中只能有一个主键约束,而却可以有多个唯一约束。通常情况下设置唯一约束的目的就是使非主键列没有重复值。唯一约束与主键约束的另一个区别是如果数据表中的某一列中有空值,那么就不能把这个列设置为主键列,而可以设置成唯一约束。例如,在商品信息表中把商品编号设置成了主键,但是还要保证商品的名称不重名时,就可以把商品名称设置为唯一约束。
(4)检查(check)约束
检查约束是用来指定表中列的值的取值范围的。例如,在员工信息表中员工年龄的列,如果要使员工年龄列的值为18~50,就可以使用检查约束进行设置,当输入的值不在有效范围内时,就会出现错误。这样就保证了数据库中数据的有效性。
(5)非空(not null)约束
非空约束是用来约束表中的列不允许为空的。例如,在员工信息表中员工身份证号码列,要求员工必须输入时,可以使用非空约束来保证该列不能为空。
3.1.5 数据库设计的完整性
使用数据库约束就是保证数据库完整性的方法。数据库设计的完整性实际上就是为了保证数据的正确性。为了保证数据的正确性,在Oracle 11g中涉及的完整性主要有3个,即实体完整性、区域完整性、参照完整性。
1. 实体完整性
实体完整性要求表中的主键字段都不能为空或者重复的值。例如,在学校里每个学生的学号是唯一的,银行卡的卡号也是唯一的,每个人的身份证号码都是唯一的等。
2. 区域完整性
区域完整性是保证输入到数据库中的数据是在有效范围内的,可以使用3.1.4小节中讲的检查约束来设置。例如,输入邮箱的字段要求要有@,输入身份证号码要有15位或18位,输入年龄只能是数字,输入姓名不能有字母等。
3. 参照完整性
参照完整性可以保证数据库中相关联的表里面数据的正确性,使用用3.1.4小节讲的外键约束就可以保证参照完整性。确保数据表的参照完整性,就可以避免误删和错加数据。例如,学生选课,如果学生已经选修了某门课程,但是管理员错误地把学生选的课程删除了,那么就会造成学生选修了课程但是无法上课,使用参照完整性设计数据表就会避免类似问题的发生。
3.2 范式—设计关系型数据库的准则
关系型数据库是目前流行和使用广泛的数据库,关系型数据库的设计标准就是数据库的范式,范式分别有第一范式、第二范式、第三范式。
3.2.1 第一范式—关系型数据库设计的第一步
目前,只要是使用关系型数据库来设计数据库,都能够满足数据库设计的第一范式。第一范式(1NF)就是数据库表中的字段都是单一属性的,不可再分。这个单一属性可以是数据库中任何一种基本数据类型,如整型、字符型、日期型等。只要是关系型数据库都会满足第一范式。例如,一个产品信息表(product),描述产品信息的字段有产品编号、产品名称、产品数量、产品价格、产品描述,如表3.4所示,那么这个产品信息表就满足第一范式的要求:每一个字段都是不可再分的单一属性。
表3.4 产品信息表(product)
3.2.2 第二范式—关系型数据库设计的第二步
第二范式是在第一范式的基础上进一步对关系型数据库进行规范,官方给出第二范式的定义是要求在数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖。意思就是说在第二范式中组合主键(AB)里面的A或者B与其他字段不能存在组合重复。为解决这个问题,通常的做法是不用组合主键,添加一个编号列,作为单一主键即可满足第二范式。如果不想添加编号列,就满足组合主键(AB)里面的A或者B与其他字段不能存在组合重复。例如,设计一个购物信息表,字段包括客户编号、产品名称、产品数量、产品类型、产品价格、客户类型。如果用客户编号和产品名称作为组合主键,那么在组合主键中产品名称和产品类型存在一定关系,是由产品名称决定产品的类型,所以不符合第二范式的要求,如果不按照第二范式的要求设计表,就会出现以下4个问题:
1. 数据冗余
同一个产品由n个顾客购买,“产品类型”就重复n-1次;同一个顾客购买了多件产品,那么就会多次记录顾客的个人信息。
2. 更新异常
若调整了某个产品的类型,数据表中所有行的“产品类型”值都要更新,否则会出现同一个产品不同类型的情况。
3. 插入异常
假设新进了一个产品,暂时还没有人购买。这样,由于没有人购买,产品的名称和类型也无法记录到数据库中。
4. 删除异常
假设一批顾客把已经购买完的商品退货,这些产品信息就从数据表中删除了。但是,与此同时,产品名称和产品类型等信息也被删除了。这样就导致了删除异常。
为了消除数据冗余、更新异常、插入异常和删除异常,可以把现有的一个表拆分成3张表:
第1张表是产品类型表,表中有产品类型、产品名称。
第2张表是客户信息表,表中有客户编号、客户类型。
第3张表是产品信息表,表中有产品名称、产品类型、产品价格、产品数量。
3.2.3 第三范式—关系型数据库设计的第三步
第三范式是在第二范式的基础上对数据库设计进行规范,第三范式的要求是数据表中不存在非关键字段对任一候选关键字段的传递函数依赖。所谓传递函数依赖,指的是如果存在A决定B、B决定C的决定关系,则C传递函数依赖于A。因此,满足第三范式的数据库表应该不存在依赖关系,假定员工信息表为employee(员工编号,姓名,年龄,所在部门,部门电话),使用员工编号作为员工信息的主键,那么就存在决定关系:员工编号就决定了姓名、年龄、所在部门、部门电话这些字段。从上面的关系可以看出,在表中有一个主键,数据表的设计符合第二范式的要求。但是它不符合第三范式的要求,因为存在决定关系:员工编号就决定了所在部门,所在部门又决定了所在部门的电话,那么就存在了传递函数依赖关系,即员工编号决定部门电话,那么也会出现不满足第二范式时的数据冗余和更新、插入、删除异常的情况。为了满足第三范式的要求,必须把员工信息表拆分成如下两个数据表:
员工表:员工编号、姓名、年龄、所在部门;
部门表:部门名称、部门电话。
说明
除了上面的三种范式以外,还有一种范式经常使用,即鲍依斯-科得范式(BCNF)。它建立在第三范式的基础上,如果数据库表中不存在任何字段对任一候选关键字段的传递函数依赖,那么就符合BCNF范式。
3.3 绘制E-R图设计数据库
E-R(Entity-Relationship)图又叫实体-联系图,是描述现实世界的概念模型。构成E-R图的基本要素是实体、属性和联系。下面就来详细地讲解如何绘制E-R图。
3.3.1 绘制E-R图的基本要素
在E-R图中涉及的基本要素有实体、联系以及属性,下面就对这3个要素进行详细说明。
(1)实体(Entity)
实体是客观存在并可以相互区别的事物。实体既可以是人、物,也可以是抽象的概念。例如,一个学生、一个老师、一个产品都可以认为是实体。相同类型的实体可以构成一个实体集。例如,全体学生就是一个实体集。在E-R图中实体一般用矩形表示,矩形框内写明实体的名称。例如,写一个老师的实体,如图3.6所示。
图3.6 老师实体的表示
(2)属性(Attribute)
属性是实体所具有的某一特性,一个实体可由若干个属性来刻画。在E-R图中一般用椭圆形表示,并用无向边将其与相应的实体连接起来。例如,产品的名称、价格、类型等都是属性。例如,给图3.6的老师实体加上属性:姓名、年龄、所教专业、所属院系,如图3.7所示。
图3.7 老师实体属性的表示
(3)联系(Relationship)
联系,即在信息世界中反映实体内部或实体之间的联系。实体内部的联系通常是指组成实体的各属性之间的联系;实体之间的联系通常是指不同实体集之间的联系。在E-R图中用菱形表示,菱形框内写明联系名,并用无向边分别与有关实体连接起来,同时在无向边旁标上联系的类型。实体之间存在着3种联系类型,分别是一对一、一对多、多对多,它们反映到E-R图中即为相应的联系类型,即1∶1、1∶n和m∶n。
❑ 一对一关系(1∶1)
一对一关系是指实体集A与实体集B,A中的每一个实体至多与B实体集中一个实体有联系;反之,在实体集B中的每个实体至多与实体集A中一个实体有联系。例如,给学生排座,“学生”实体和“座位”实体之间的关系,每一个学生最多可以分得一个座位,同时每一个座位最多只能有一个学生来坐。用图形表示如图3.8所示。
图3.8 一对一关系
❑ 一对多关系(1∶n)
一对多关系是指实体集A与实体集B中至少有n(n>0)个实体有联系,并且实体集B中每一个实体至多与实体集A中一个实体有联系。例如,“学生”实体和“班级”实体之间的关系,一个班级里面可以有若干个学生,而每一个学生都属于这个班级。用图形表示如图3.9所示。
❑ 多对多关系(m∶n)
多对多关系是指实体集A中的每一个实体与实体集B中至少m(m>0)个实体有联系,并且实体集B中的每一个实体与实体集A中的至少n(n>0)个实体有联系。例如,顾客在商场购买商品,顾客与商品之间就是多对多的关系,每一个顾客都可以购买多种商品,而每一种商品又可以被多个顾客购买。用图形表示如图3.10所示。
其实,实体之间的这3种关系,不仅对两个实体有效,也可以表示多个实体之间的关系。
图3.9 一对多关系
图3.10 多对多关系
3.3.2 E-R图绘制实例
绘制一个网上购物系统的E-R图,在网上购物系统中简单分析出顾客、商品、商品类型、订单4个实体。下面分别绘制每个实体属性图并在最后绘制一个整体的E-R图。
1. 顾客实体属性图
顾客实体主要包括用户编号、姓名、年龄、性别、身份证号、联系方式、送货地址、银行卡卡号8个属性,实体属性图如图3.11所示。
2. 商品实体属性图
商品实体主要包括商品编号、商品名称、商品价格、商品数量、商品描述5个属性,实体属性图如图3.12所示。
3. 商品类型实体属性图
商品类型实体主要包括商品类型编号和商品类型两个属性,实体属性图如图3.13所示。
4. 订单实体属性图
订单实体主要包括订单编号、送货地址、顾客姓名、是否付款、联系方式、所购商品6个属性,实体属性图如图3.14所示。
图3.11 顾客实体属性图
图3.12 商品实体属性图
图3.13 商品类型实体属性图
图3.14 订单实体属性图
5. 网上购物系统E-R图
在绘制整体的E-R图之前,先要了解一下网上购物系统的购物流程。首先由顾客选择要购买的商品,之后把购买商品的列表生成一个订单,然后网站的售后人员会根据订单的地址送货,在这个网上购物系统里要求一个顾客每次只能生成一个订单。那么,这4个实体之间是什么关系呢?首先商品和顾客之间的关系是多对多的关系,多个商品可以被一个顾客购买,同时多个顾客也可以购买相同的商品;订单和商品之间的关系是一对多的关系,一个订单是由多个商品组成的,多个商品组成一个订单;顾客和订单之间的关系是一对一的关系,一个顾客可以生成一个订单,一个订单只能属于一个顾客;商品和商品类型之间的关系是一对一的关系,一个商品属于一种商品类型。网上购物系统的E-R图如图3.15所示。
图3.15 网上购物系统E-R图
3.4 小结
通过本章的学习,用户可以了解数据库的历史,掌握关系型数据库设计的规则,即范式的使用,以及使用E-R图绘制数据库中表之间的联系。这些知识也是数据库的基础。此外,本章在介绍数据库历史和设计数据库的基础上,还对数据库中常用的术语,即表、视图、存储过程、触发器以及约束做了简单的介绍,方便读者学习本书后面的章节。
3.5 习题
简答题
1. 在数据管理的人工阶段,数据的存放主要用什么?
2. 简述数据库的三级模式。
3. 什么是E-R图?并绘制一个选课系统的E-R图。
4. 设计一张符合第三范式的数据库表。
5. Oracle 11g是什么类型的数据库?