数据库系统管理课件(王岚主编)第十一章.ppt
- 文档编号:10134326
- 上传时间:2023-05-23
- 格式:PPT
- 页数:69
- 大小:244.50KB
数据库系统管理课件(王岚主编)第十一章.ppt
《数据库系统管理课件(王岚主编)第十一章.ppt》由会员分享,可在线阅读,更多相关《数据库系统管理课件(王岚主编)第十一章.ppt(69页珍藏版)》请在冰点文库上搜索。
数据库基础,第十一章关系数据库规范化理论,数据库基础,【本章要点】,本章主要讨论关系数据库规范化理论,讨论一个好的关系模式的标准,以及如何将不好的关系模式转换成好的关系模式,并能保证所得到的关系模式仍能表达原来的语义。
数据库基础,第十一章关系数据库规范化理论,数据库设计是数据库应用领域的主要研究课题。
数据库设计的任务是在给定的应用环境下,创建满足用户需求且性能良好的数据库模式,建立数据库及其应用系统,使之能有效地存储和管理数据,满足某公司或部门各类用户业务的需求。
数据库基础,第十一章关系数据库规范化理论,数据库设计需要理论指导,关系数据库规范化理论就是数据库设计的一个理论指南。
规范化理论研究了关系模式中各属性之间的依赖关系及其对关系模式性能的影响,探讨“好”的关系模式应该具备的性质,以及达到“好”的关系模式的方法。
规范化理论为我们提供了判断关系模式好坏的理论标准,帮助我们预测可能出现的问题,是数据库设计人员的有力工具,同时也使数据库设计工作有了严格的理论基础。
数据库基础,第十一章关系数据库规范化理论,本章主要讨论关系数据库规范化理论,讨论一个好的关系模式的标准,以及如何将不好的关系模式转换成好的关系模式,并能保证所得到的关系模式仍能表达原来的语义。
数据库设计是数据库应用领域的主要研究课题。
数据库设计的任务是在给定的应用环境下,创建满足用户需求且性能良好的数据库模式,建立数据库及其应用系统,使之能有效地存储和管理数据,满足某公司或部门各类用户业务的需求。
数据库基础,第十一章关系数据库规范化理论,数据库设计需要理论指导,关系数据库规范化理论就是数据库设计的一个理论指南。
规范化理论研究了关系模式中各属性之间的依赖关系及其对关系模式性能的影响,探讨“好”的关系模式应该具备的性质,以及达到“好”的关系模式的方法。
规范化理论为我们提供了判断关系模式好坏的理论标准,帮助我们预测可能出现的问题,是数据库设计人员的有力工具,同时也使数据库设计工作有了严格的理论基础。
数据库基础,第十一章关系数据库规范化理论,本章主要讨论关系数据库规范化理论,讨论一个好的关系模式的标准,以及如何将不好的关系模式转换成好的关系模式,并能保证所得到的关系模式仍能表达原来的语义。
数据库基础,第十一章关系数据库规范化理论,11.1函数依赖11.2关系规范化11.3关系模式分解的准则,数据库基础,11.1函数依赖,数据的语义不仅表现为完整性约束,对关系模式的设计也提出了一定的要求。
针对一个问题,如何构造一个合适的关系模式,应构造几个关系模式,每个关系模式由哪些属性组成等,这都是数据库设计问题,确切地讲是关系数据库的逻辑设计问题。
首先我们看一下,关系模式中各属性之间的联系。
数据库基础,11.1函数依赖,11.1.1函数依赖的基本概念11.1.2一些术语和符号11.1.3为什么要讨论函数依赖,数据库基础,11.1.1函数依赖的基本概念,在关系数据库中,讨论函数或函数依赖注重的是语义上的关系。
x函数决定y,或y函数依赖于x可表示为:
XY根据以上讨论可以写出较直观的函数依赖定义,即如果有一个关系模式R(A1,A2,An),X和Y为A1,A2,An)的子集,那么对于关系R中的任意一个x值,都只有一个y值与之对应,则称X函数决定Y,或Y函数依赖于X。
数据库基础,11.1.1函数依赖的基本概念,例如,对学生关系模式Student(Sno,Sname,Sdept,Sage),有以下依赖关系SnoSname,SnoSdept,SnoSage对学生选课关系模式SC(Sno,Cno,Grade)有以下依赖关系:
(Sno,Cno)Grade,数据库基础,11.1.1函数依赖的基本概念,显然,函数依赖讨论的是属性之间的依赖关系,它是语义范畴的概念,也就是说关系模式的属性之间是否存在函数依赖只与语义有关。
下面对函数依赖给出严格的形式化定义。
设有关系模式R(A1,A2,An),r是R的任一具体关系,t1,t2是r中的任意两个元组。
如果由t1X=t2X可以推导出t1Y=t2Y,则称X函数决定Y,或Y函数依赖于X,记为XY。
数据库基础,11.1函数依赖,11.1.1函数依赖的基本概念11.1.2一些术语和符号11.1.3为什么要讨论函数依赖,数据库基础,11.1.2一些术语和符号,下面给出在本章中经常使用的一些术语和符号。
设有关系模式R(A1,A2,An),X和Y为(A1,A2,An)的子集,则有以下结论:
1)如果XY,但Y不包含于X,则称XY是非平凡的函数依赖。
如不作特别说明,我们总是讨论非平凡函数依赖。
2)如果Y函数不依赖于X,则记为。
3)如果XY,则称X称为决定因子。
数据库基础,11.1.2一些术语和符号,4)如果XY,并且YX,则记为。
5)如果XY,并且对于x的一个任意真子集X都有,则称Y完全函数依赖于X,记为。
如果成立,则称Y部分函数依赖于X,记为。
6)如果XY(非平凡函数依赖,并且)、YZ,则称Z传递函数依赖于X。
数据库基础,11.1.2一些术语和符号,例11.1假设有关系模式SC(sno,Sname,Cno,Grade),其中各属性分别为:
学号、姓名、课程号、成绩,主码为(sno,Cno),则函数依赖关系有:
SnoSname姓名函数依赖于学号(sno,Cno)Sname姓名部分函数依赖于学号和课程号(sno,Cno)Grade成绩完全函数依赖于学号和课程号,数据库基础,11.1.2一些术语和符号,例11.2假设有关系模式S(Sno,Sname,Dept,Dept_master),其中各属性分别为:
学号、姓名、所在系和系主任(假设一个系只有一个主任),主码为Sno,则函数依赖关系有:
SnoSname姓名完全函数依赖于学号由于:
SnoDept所在系完全函数依赖于学号DeptDept_master系主任完全函数依赖于系系主任传递函数依赖于学号所以有:
SnoDept_master函数依赖是数据的重要性质,关系模式应能反映这些性质。
数据库基础,11.1函数依赖,11.1.1函数依赖的基本概念11.1.2一些术语和符号11.1.3为什么要讨论函数依赖,数据库基础,11.1.3为什么要讨论函数依赖,讨论属性之间的关系和函数依赖有什么意义呢?
让我们通过例子看一下。
假设有描述学生选课及住宿情况的关系模式:
S_L_C(Sno,Sdept,Sloc,Cno,Grade)其中各属性分别为:
学号、学生所在系、学生所住宿舍楼、课程号和考试成绩。
假设每个系的学生都住在一栋楼里,(Sno,Cno)为主码。
看一看这个关系模式存在什么问题?
假设有如表11-1所示的数据。
数据库基础,11.1.3为什么要讨论函数依赖,表11-1S_L_C模式的数据示例,数据库基础,11.1.3为什么要讨论函数依赖,从这个表中可以看出如下问题:
数据冗余问题:
在这个关系中,有关学生所在系和其所对应的宿舍楼的信息有冗余,因为一个系有多少个学生,这个系所对应的宿舍楼的信息就要重复存储多少遍。
数据更新问题:
如果某一学生从计算机系转到了信息系,那么不但要修改此学生的Sdept列的值,而且还要修改其Sloc列的值,从而使修改复杂化。
数据库基础,11.1.3为什么要讨论函数依赖,数据插入问题:
如果某个学生还没有选课,但已经有了Sdept乘lSloc信息,我们也不能将此学生的这些已知信息插入到数据库中。
因为Cno为空,而Cno为主属性,不能为空,因此也就丢掉了该学生的其它基本信息。
数据删除问题:
如果一个学生只选了一门课,而后来又不选了,则应该删除此学生选此门课程的记录。
但由于这个学生只选了一门课,那么删掉此学生的选课记录的同时也删掉了此学生的其它基本信息。
数据库基础,11.1.3为什么要讨论函数依赖,类似的问题我们统称为操作异常。
为什么会出现以上的操作异常现象呢?
因为这个关系模式没有设计好,其原因在于它的某些属性之间存在着“不良”的函数依赖。
如何改造这个关系模式并克服以上种种问题是我们所要解决的问题,也是我们讨论函数依赖的原因。
解决上述问题的方法就是进行模式分解,即把一个关系模式分解成两个或多个关系模式,在分解的过程中消除那些“不良”的函数依赖,从而获得好的关系模式。
关于模式分解将在本章后边介绍。
数据库基础,第十一章关系数据库规范化理论,11.1函数依赖11.2关系规范化11.3关系模式分解的准则,数据库基础,11.2关系规范化,11.2.1关系模式中的码11.2.2范式,数据库基础,11.2.1关系模式中的码,设用U表示关系模式R的属性全集,即U=A1,A2,An,用F表示关系模式R上的函数依赖集,则关系模式R可表示为R(U,F)。
1候选码设K为R(U,F)中的属性或属性组,若KU,则K为R的候选码(K为决定R全部属性值的最小属性组)。
主码:
关系R(U,F)中可能有多个候选码,则选其中一个作为主码。
全码:
候选码为整个属性组。
主属性与非主属性:
在R(U,F)中,包含在任一候选码中的属性称为主属性,不包含在任一候选码中的属性称为非主属性。
数据库基础,11.2.1关系模式中的码,例11.3SC(Sno,Cno,Grade)其候选码为:
(Sno,Cno),也为主码。
则主属性为:
Sno和Cno,Grade为非主属性。
数据库基础,11.2.1关系模式中的码,例11.4R(P,W,A)其中各属性含义分别为:
演奏者,作品和演出地点。
其语义为:
一个演奏者可演奏多个作品,某一作品可被多个演奏者演奏;同一演出地点不同演奏者的不同作品。
其候选码为(P,W,A),因为只有(演奏者,作品,演出地点)三者才能确定一场音乐会。
我们称全部属性均为主码的表为全码表。
数据库基础,11.2.1关系模式中的码,2外码用于在关系表之间建立关联的属性(组)称为为外码。
若R(U,F)的属性(组)X(X属于U)是另一个关系S的主码,则称X为R的外码(X必须先定义为S的主码)。
数据库基础,11.2关系规范化,11.2.1关系模式中的码11.2.2范式,数据库基础,11.2.2范式,我们在前面已经介绍了设计“不好”的关系模式所带来的问题,本节将继续讨论“好”的关系模式应具备的性质,即关系规范化问题。
关系数据库中的关系要满足一定的要求。
若关系满足不同程度要求就称它属于不同的范式。
满足最低要求的关系属于第一范式,简称1NF(FirstNormalForm)。
在第一范式中进一步满足一些要求的关系属于第二范式,简称2NF,依此类推,还有3NF、BCNF、4NF、5NF。
数据库基础,11.2.2范式,所谓“第几范式”是表示关系模式满足的条件,所以经常称某一关系模式为第几范式的关系模式。
也可以把这个概念模式理解为符合某种条件的关系模式的集合,因此R为第二范式的关系模式也可以写为R2NF。
数据库基础,11.2.2范式,对关系模式的属性间的函数依赖加以不同的限制就形成了不同的范式。
这些范式是递进的,即如果一个表是1NF的,它比不是1NF的要好;同样,2NF的表要比1NF的表好,。
使用这种方法的目的是从一个表或表的集合开始,逐步产生一个和初始集合等价的表的集合(指提供同样的信息)。
范式越高、规范化的程度越高,关系模式就越好。
规范化的理论首先由EFCodd于1971年提出,其目的是要设计“好的”关系数据库模式。
关系规范化实际就是对有问题(操作异常)的关系进行分解从而消除这些异常。
数据库基础,11.2.2范式,1第一范式每一个数据项都是不可再分的是第一范式的关系。
2第二范式如果R(U,F)1NF,并且R中的每个非主属性都完全函数依赖于主码,则R(U,F)2NF。
数据库基础,11.2.2范式,从定义中可以看出,若某个1NF的关系的主码只由一个列组成,那么这个关系就是2NF关系。
但是,如果主码是由多个属性列共同构成的复合主码,并且存在非主属性对主属性的部分函数依赖,则这个关系就不是2NF关系。
数据库基础,11.2.2范式,例如,前面所示的S_L_C(Sno,Sdept,Sloc,Cno,Grade)关系就不是2NF的。
因为(Sno,Cno)是主码,而又有SnoSdept,因此有(Sno,Cno)Sdept即存在非主码属性对主码的部分函数依赖关系,所以此S_L_C关系不是2NF的。
前面已经介绍过这个关系存在操作异常,而这些操作异常就是因为它存在部分函数依赖造成的。
可以用模式分解的办法将非2NF的关系模式分解为多个2NF的关系模式。
数据库基础,11.2.2范式,S_L_C关系模式分解后的形式为:
S_L(Sno,Sdept,Sloc)和S_C(Sno,Cno,Grade)。
S_L关系的主码是(Sno),并且有SnoSdept,SnoSloc,所以S_L是2NF的。
S_C关系的主码是(Sno,Cno),并且有(Sno,Cno)Grade,因此S_C也是2NF的。
数据库基础,11.2.2范式,下面我们看一下分解完之后是否还存在问题,先讨论S_L表。
首先,在这个关系模式中,描述多少个学生就会将每个系和其所在的宿舍楼重复描述多少遍,因此还存在数据冗余。
其次,当新组建一个系时,如果此系还没有招收学生,但已分配了宿舍楼,则无法将此系的信息插入到数据库中,因为这时的学号为空。
这是插入异常。
由此我们看到,第二范式的表也可能存在操作异常情况,因此还要对此关系模式进行进一步的分解。
数据库基础,11.2.211.2.2范式范式,3第三范式如果R(U,F)2NF,并且所有非主属性都不传递依赖于主码,则R(U,F)3NF。
从定义中可以看出,如果存在非主属性对主码的传递依赖,则相应的关系模式就不是3NF的。
以关系模式S_L(Sno,Sdept,Sloc)为例,因为SnoSdept,SdeptSloc所以SnoSloc。
数据库基础,11.2.2范式,从前边的定义中可以知道,当关系模式中存在传递函数依赖时,这个关系模式仍然有操作异常,因此还需要对其进行进一步的分解。
S_L分解后的关系模式为:
S_D(Sno,Sdept)(主码为Sno)和D_L(Sdept,Sloc)(主码为Sdept)对S_D,有SnoSdept,因此S_D是3NF的。
对D_L,有SdeptSloc,因此S_L也是3NF的。
由于3NF关系模式中不存在非主码属性对主码的部分依赖和传递依赖关系,因而在很大程度上消除了数据冗余和更新异常,因此在通常的数据库设计中,一般要求要达到3NF。
数据库基础,11.2.2范式,4BCNFBCNF也叫BoyceCodd范式,它是3NF的进一步规范化,其限制条件更严格。
我们首先分析一下3NF中存在的问题。
在3NF的关系模式中可能存在能够决定其它属性取值的属性组,而该属性组非码。
例如,假设有关系模式CSZ(city,Street,zip),其中各属性分别代表城市、街道和邮政编码。
其语义为:
城市和街道可以决定邮政编码,邮政编码可以决定城市。
因此有:
(City,Street)Zip,ZipCity其候选码为(city,street)和(street,zip),此关系模式中不存在非主属性,因此它属于3NF。
数据库基础,11.2.2范式,现在我们看一下此模式存在的问题。
假设取(City,street)为主码,则当插入数据时,如果没有街道信息,则一个邮政编码是哪个城市的邮政编码这样的信息就无法保存到数据库中,因为Street不能为空。
由此可见,即使是3NF的表,也有可能存在操作异常。
操作异常的原因是存在ZipCity,Zip是决定因子,但Zip不是码。
数据库基础,11.2.2范式,在3NF关系模式中之所以存在操作异常,主要是存在主属性对非码的函数依赖。
在这种情况下,产生了BCNF。
若关系模式R1NF,且能决定其它属性取值的属性(组)必定包含码,则RBCNF。
可以将该定义理解为,如果一个关系的每个决定因子都是候选码,则其是BCNF。
或者说,如果R3NF,并且不存在主属性对非码的函数依赖,则其是BCNF。
数据库基础,11.2.2范式,将CSZ分解分解为:
ZC(Zip,City),SZ(Street,Zip)。
这样就去掉了决定因子不包含码的情况,它们都是BCNF的关系模式了。
如果一个模型中的所有关系模式都属于BCNF,那么在函数依赖范畴内,就实现了彻底的分解,消除了操作异常。
也就是说,在函数依赖的范畴,BCNF达到了最高的规范化程度。
1NF、2NF、3NF和。
BCNF的相互关系是:
BCNF3NF2NF1NF。
数据库基础,第十一章关系数据库规范化理论,11.1函数依赖11.2关系规范化11.3关系模式分解的准则,数据库基础,11.3关系模式分解的准则,前面已经介绍过,为了提高规范化程度,通常将范式程度低的关系模式分解为若干个范式程度高的关系模式。
每个规范化的关系应该只有一个主题,如果某个关系描述了两个或多个主题,就应该将它分解为多个关系,使每个关系只描述一个主题。
当我们发现一个关系存在操作异常时,就应该把关系分解为两个或多个单独的关系,使每个关系只描述一个主题,从而消除这些异常。
数据库基础,11.3关系模式分解的准则,从而消除这些异常。
规范化的方法是进行模式分解,但分解后产生的模式应与原模式等价,即模式分解必须遵守一定的准则,不能表面上消除了操作异常现象,却留下了其它的问题。
模式分解要满足以下标准:
1)模式分解具有无损连接性。
2)模式分解能够保持函数依赖。
数据库基础,11.3关系模式分解的准则,无损连接是指分解后的关系通过自然连接可以恢复成原来的关系,即通过自然连接得到的关系与原来的关系相比,既不多出信息、又不丢失信息。
保持函数依赖的分解是指在模式的分解过程中函数依赖不能丢失的特性,即模式分解不能破坏原来的语义。
为了得到更高范式的关系而进行的模式分解是否总能既保证无损连接、又保持函数依赖呢?
答案是否定的。
数据库基础,11.3关系模式分解的准则,那么应如何对关系模式进行分解呢?
在不同情况下,同一个关系模式可能有多种分解方案。
例如,对于关系模式S_D_L(Sno,Dept,Loc)(其中各属性含义分别为学号、系名和宿舍楼号,假设系名可以决定宿舍楼号),有如下函数依赖:
SnoDept,DeptLoc,数据库基础,11.3关系模式分解的准则,显然这个关系模式不是第三范式的。
此关系模式至少可以有三种分解方案,分别为:
方案1:
S_L(Sno,Loc),D_L(Dept,Loc)方案2:
S_D(Sno,Dept),S_L(Sno,Loc)方案3:
S_D(Sno,Dept),D-L(Dept,Loc),数据库基础,11.3关系模式分解的准则,使用这三种分解方案得到的关系模式都是第三范式的,那么如何比较这三种方案的好坏呢?
由此我们想到,在将一个关系模式分解为多个关系模式时除了提高规范化程度之外,还要考虑其它一些因素。
数据库基础,11.3关系模式分解的准则,将一个关系模式R分解为若干个关系模式R1,R2,Rn(其中U=U1U2Un,Fi为F在Ui上的投影),这意味着相应地将存储在一张二维表r中的数据分散到了若干个二维表r1,r2,rn中(ri是r在属性组Ui上的投影)。
我们当然希望这样的分解不丢失信息,也就是说,对关系r1,r2,rn进行自然连接运算后能重新得到关系r的所有信息。
数据库基础,11.3关系模式分解的准则,事实上,要想在关系r投影r1,r2,rn时不会丢失信息,关键是对r1,r2,rn做自然连接时可能产生一些r中原来没有的元组,从而无法区别哪些元组是r中原来有的,即数据库中应该存在的数据,哪些是不应该有的。
从这个意义上说就丢失了信息。
仍以关系模式S_D_L(Sno,Dept,Loc)为例,按三种分解方案得到的关系模式是否满足分解要求呢?
我们对此进行一些分析。
数据库基础,11.3关系模式分解的准则,假设在某一时刻,此关系模式的数据如表11-2所示,此关系用r表示。
表11-2关系r,数据库基础,11.3关系模式分解的准则,若按方案1将关系模式S_D_L分解为S_L(Sno,Loc)和D_L(Dept,Loc),则将S_D_L投影到S_L和D_L的属性上,得到关系r11和r12,如表11-3和11-4所示。
表11-3关系r11,数据库基础,11.3关系模式分解的准则,表11-4关系r12,数据库基础,11.3关系模式分解的准则,将r11和r12进行自然连接r11*r12得到r,如表11-5所示。
表11-5关系r,数据库基础,11.3关系模式分解的准则,r中的元组(S01,D3,L1)和(S04,Dl,L1)不是原来r中的元组,因此,我们无法知道原来的r中到底有哪些元组,这当然是我们所不希望的。
所以,将关系模式R分解为关系模式R1,R2,Rn时,若对于R中的任何一个可能的r,都有r=r1*r2*rn,即r在R1,R2,Rn上的投影的自然连接等于r,则称关系模式R的分解具有无损连接性。
分解方案1不具有无损连接性,因此不是一个好的分解方法。
数据库基础,11.3关系模式分解的准则,再分析方案2。
将S_D_L投影到S_D,S_L的属性上,得到关系r21和r22,如表11-6和表11-7所示。
表11-6关系r21,数据库基础,11.3关系模式分解的准则,表11-7关系r22,数据库基础,11.3关系模式分解的准则,将r21*r22做自然连接,得到r”,如表11-8所示。
表11-8关系r,数据库基础,11.3关系模式分解的准则,我们看到,分解后的关系模式经过自然连接后恢复成了原来的关系,因此分解方案2具有无损连接性。
现在我们对这个分解做进一步的分析。
假设学生S03从D2系转到了D3系,于是我们需要在r21中将元组(S03,D2)改为(S03,D3),同时还需要在r22中将元组(S03,L2)改为(S03,L1)。
如果这两个修改没有同时进行,则数据库中就会出现不一致信息。
这是由于这样分解得到的两个关系模式没有保持原来的函数依赖关系造成的。
原有的函数依赖DeptLoc在分解后即没有投影到S_D中,也没有投影到S_L中,而是跨在了两个关系模式上。
因此分解方案2没有保持原有的函数依赖关系,它也不是好的分解方法。
数据库基础,11.3关系模式分解的准则,我们看分解方案3,经过分析可以看出分解方案3既满足无损连接性,又保持了原有的函数依赖关系,因此它是一个好的分解方法。
总结以上分析可以看出,分解具有无损连接性和分解保持函数依赖是两个独立的标准。
具有无损连接性的分解不一定保持函数依赖(如前边的分解方案2),保持函数依赖的分解不一定具有无损连接性(请读者自己想例子来说明这种情况)。
一般情况下,在进行模式分解时,我们应将有直接依赖关系的属性放置在一个关系模式中,这样得到的分解结果一般既能具有无损连接性,也能保持函数依赖关系不变。
数据库基础,小结,关系规范化理论是设计没有操作异常的关系数据库表的基本原则。
规范化理论主要研究关系表中各属性之间的依赖关系。
根据依赖关系的不同,我们介绍了不包含子属性的第一范式,消除了属性问的部分依赖关系的第二范式,消除了属性间的传递依赖关系的第三范式,最后到每个决定因子都必须是码的BCNF。
范式的每一次升级都是通过模式分解实现的,在进行模式分解时应注意保持分解后的关系能够具有无损连接性并能保持原有的函数依赖关系。
数据库基础,小结,关系规范化理论的根本目的是指导我们设计没有数据冗余和操作异常的关系模式。
对于一般的数据库应用来说,设计到第三范式就足够了。
因为规范化程度越高,表的个数也就越多,因而有可能降低数据的查询效率。
数据库基础,习题,1关系规范化中的操作异常有哪些?
它是由什么原因引起的?
解决的办法是什么?
2设有关系模式:
Studentl(学号,姓名,出生日期,所在系,宿舍楼),其语义为:
一个学生只在一个系学习,一个系的学生只住在一个宿舍楼里。
指出此关系模式的候选码,判断此关系模式是第几范式的。
若不是第三范式的,请将其规范化为第三范式关系模式,并指出分解后的每个关系模式的主码和外码。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 系统管理 课件 主编 第十一
![提示](https://static.bingdoc.com/images/bang_tan.gif)