赞
踩
数据库知识
(1)数据库模型(概念模式、外模式、内模式)
(2)数据模型,ER图,规范化
(3)数据操作
(4)数据库语言
(5)数据库管理系统的功能和特征
(6)数据库的控制功能
(7)数据仓库和分布式数据库基础知识
数据库建模
(1)设计关系模式:掌握给定一个实际的应用问题如何设计E-R模型,如何将E-R模型转换成关
系模式,确定联系类型、主键、候选键、外键,判断关系模式规范化的程度。
(2)数据库语言(SQL):掌握给定一个实际的应用问题如何用SQL进行数据定义(创建表、
视图)、完整性定义及权限定义。
(3)数据库访问:掌握常用数据库的访问方法。
考点主要集中在:E-R模型、关系代数、元组演算、规范化理论(键、范式、模式分解)、SQL语言等。
考点主要有:E-R模型、关系模式、主键、外键,偶尔出现SQL语言方面的试题。
数据库是长期存储在计算机内的、有组织的、可共享的数据集合,数据库系统是指在计算机信息系统中引入数据库后的系统,一般由数据库、数据库管理系(DataBaseManagementSystem,DBMS)、应用系统、数据库管理员(DataBase Administrator,DBA)和用户构成。
数据库系统的结构可以有多种不同的层次 或不同的角度,其中典型的是三级划分法 ,其中包括三级模式和两级映射 。下面将就该主题,以及ER模型 展开论述.
从图5-1可以看出,整个数据库体系由数据库管理系统(DBMS)进行管理,其内容涉及底层的数据存储问题,顶层涉及与用户的交互,这种层次的划分,主要目标是使数据库体系内部耦合度更低,变得更为灵活。
从图5-1可以看出,三级模式实际对应着数据库系统中的三个层次,这三个层次划分出来以后,为了达到“一个层次的变化不对其它两个层产生影响”的效果,提出了两级映射 。两级映射分别是:外模式与概念模式之间的映射、概念模式与内模式之间的映射。
ER模型:
数据库系统是对现实世界中数据的一种抽象,正如在“数据库系统功能和特性”知识点中所描述的,首先我们将通过概念模型将现实世界抽象成为信息世界,然后再抽象成为基本数据模型。而最常使用的概念模型就是E-R模型 ,本知识点则主要围绕着这个重要概念阐述。
图5-2 展示了一个简单的ER模型,我们通过该图进行ER模型的概念入门:
实体 :客观存在并可相互区别的事物,可以是具体的人、事、物,也可以是抽象的概念或联系。图5-2中的**“学生”与“课程”** 便是实体。
属性 :实体所具有的某一特性称为属性,通常一个实体可以由多个属性来描述。图5-2中“学生”实体旁边的**“学号”、“姓名”、“班级号”** 便是属性。
联系 :实体内部的联系通常是指组成实体的各属性间的关系。图5-2中**“选课”便是联系** 。
(1)ER模型实体联系类型
一对一联系(1:1):对于实体集A中的每一个实体,实体集B中至多有一个实体与之联系。例:一个班级只有一个班主任 ,一个班主任也只在一个班级中任职。
一对多联系(1:n):对于实体集A中的每一个实体,实体集B中有n(n>0)个实体与之联系。反之,实体集B中的每一个实体,实体集A中至多只有一个实体与之联系。例:一个班级中有许多学生 ,而每个学生只在一个班级中学习。
多对多联系(m:n):对于实体集A中的每一个实体,实体集B中有n(n>0)个实体与之联系。反之,实体集B中的每一个实体,实体集A中有m(m>0)个实体与之联系。一门课程同时有许多学生选修,而一个学生也可以选修多门课程 。如图5-2所示,该ER模型便属于m:n型。
(2)E-R模型的集成
在数据库的概念设计过程中,由于系统都存在一定的复杂度,一次性设计全局E-R图将存在较大风险,所以一般会先设计各子系统的局部E-R图 ,然进行集成。
但由于各子系统应用所面临的问题不同,且通常是由不同的设计人员进行局部视图设计,这就导致各个局部E-R图之间必定会存在许多不一致的问题,称之为冲突。因此,在合并E-R图时,不能简单地将各个局部E-R图画到一起,而是必须着力消除各个局部E-R图中的不一致,以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。
各局部E-R图之间的冲突主要有三类 ,分别是属性冲突、命名冲突和结构冲突。
1)属性冲突 。属性冲突包括属性域冲突和属性取值冲突 。属性冲突理论上好解决,只要换成相同的属性就可以了,但实际上需要各部门协商,解决起来并不简单。
2)命名冲突 。命名冲突包括同名异义和异名同义 。处理命名冲突通常也像处理属性冲突一样,通过讨论和协商等行政手段加以解。
3)结构冲突 。结构冲突包括同一对象在不同应用中具有不同的抽象 ,以及同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。对于前者的解决办法是将属性变换为实体或实体变换为属性,使同一对象具有相同的抽象。对于后者的解决办法是使该实体的属性取各局部E-R图中属性的并集,再适当调整属性的次序。
(3)E-R模型转关系模式
E-R图向关系模式的转换属于数据库的逻辑设计阶段 的工作,该阶段需要将E-R模型转换为某种DBMS能处理的关系模式 ,具体转换规则如下:
1)一个实体转换为一个关系模式,实体的属性就是关系的属性,实体的主键就是关系的主键 。
2)一个1:1联系可以转换为一个独立的关系模式 ,也可以与任意一端对应的关系模式合并 。如果转换为一个独立的模式,则与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性,每个实体的主键均是该关系的键属性;如果与某一端实体对应的关系模式合并,则需要在该关系模式的属性中加入另一个关系模式的主键和联系本身的属性。
3)一个1:n联系可以转换为一个独立的关系模式 ,也可以与任意n端对应的关系模式合并 。如果转换为一个独立的模式,则与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性,而关系的主键为n端实体的主键;如果与n端实体对应的关系模式合并,则需要在该关系模式的属性中加入端关系模式的主键和联系本身的属性。
4)一个m:n联系转换为一个独立的关系模式,与该联系相连的各实体的主键以及联系本身的属性均转换为关系的属性,而关系的主键为各实体主键的组合。
5)三个以上实体间的一个多元联系可以转换为一个独立的关系模式,与该联系相连的各实体的主键和联系本身的属性均转换为关系的属性,而关系的主键为各实体主键的组合。
另外,还有三种情况是需要特别注意的:
1)多值属性的处理。如果E-R图中某实体具有一个多值属性,则应该进行优化,把该属性提升为一个实体,通常称为弱实体;或者在转化为关系模式时,将实体的主键与多值属性单独构成一个关系模式。
2)派生属性的处理。因为派生属性可由其他属性计算得到,因此,在转化成关系模式时,通常不转换派生属性。
3)在面向对象模型中,关系模式就对应类,关系模式的属性就对应类的属性。
关系运算:关系代数的基本运算主要有并、交、差、笛卡尔积、选择、投影、连接和除法运算。
元组演算:在元组演算中,元组演算表达式简称为元组表达式,其一般形式为{t|P(t)},其中,t是元组变量,表示一个元数固定的元组;P是公式,在数理逻辑中也称为谓词,也就是计算机语言中的条件表达式。{t|P(t)}表示满足公式P的所有元组t的集合。
规范化理论的作用:
不同的人对于相同的东西可以建立不同的模型,如何衡量模型建立的好坏?换而言之,按照什么原则建立模型?这个原则就是规范化理论 。
前面已经介绍了什么是规范化理论,那么在数据库设计中,规范化理论有什么作用,解决了什么问题呢?下面我们通过一个实例来分析这个问题。
设有一个关系模式R(SNAME,CNAME,TNAME TADDRESS),其属性分别表示学生姓名、选修的课程名、任课教师姓名和任课教师地址。仔细分析一下,就会发现这个模式存在下列存储异常的问题:
(1)数据冗余:如果某门课程有100个学生选修,那么在R的关系中就要出现100个元组 ,这门课程的任课教师姓名和地址也随之重复出现100次。
(2)修改异常:由于上述冗余问题,当需要修改这个教师的地址时,就要修改100个元组中的地址值,否则就会出现地址值不一致的现象。
(3)插入异常:如果不知道听课学生名单,这个教师的任课情况和家庭地址就无法进入数据库;否则就要在学生姓名处插入空值。
(4)删除异常:如果某门课程的任课教师要更改,那么原来任课教师的地址将随之丢失。因此,关系模式R虽然只有四个属性,但却是性能很差的模式。产生这些异常的原因与关系模式属性值之间的联系直接有关。在模式R中,学生与课程有直接联系,教师与课程有直接联系,而教师与学生无直接联系,这就产生了模式R的存储异常。如果将R分解成下列两个关系模式:R1(SNAME,CNAME)和R2(CNAME,TNAME,TADDRESS),则能消除上述的存储异常现象。
函数依赖:
函数依赖是数据库的一种约束,决定了关系模式属于哪种范式 。为了理解方面,下面我们先介绍函数依赖的有关概念。
设R(U)是属性U上的一个关系模式,X和Y是U的子集,r为R的任一关系,如果对于r中的任意两个元组u,v,只要有u[X]=v[X],就有u[Y]=v[Y],则称X函数决定Y,或称Y函数依赖于X,记为X→Y。
例如,记录职工信息的结构如下:
职工工号(EMP_NO)
职工姓名(EMP_NMAE)
所在部门(DEPT)。
我们说EMP_NO函数决定EMP_NMAE和DEPT,或者说EMP_NMAE,DEPT函数依赖于EMP_NO,记为:EMP_NO→EMP_NMAE,EMP_NO→DEPT
键:
超键:在关系模式中,能唯一标识元组 的属性集称为超键。
候选键:如果一个属性集能唯一标识元组 ,且又不含有多余属性。
主键:关系模式中用户正在使用的候选键称为主键。
外键:如果公共关键字在一个关系中是主关键字,那么这个公共关键字被称为另一个关系的外键。
例如,记录职工信息的结构如下:
职工工号(EMP_NO)
职工身份证号(EMP_CARDID)
职工姓名(EMP_NMAE)
职工性别(EMP_SEX)
所在部门编号(DEPT_NO)。
在此关系中:
(1)EMP_NO和EMP_NMAE的组合是超键。
理由:EMP_NO和EMP_NMAE的组合能唯一标识元组的属性。
补充说明:其实只需要EMP_NO就可以唯一标识元组的属性,所以EMP_NO是本关系的候选键,也可以是本关系的主键。
(2)EMP_NO 和EMP_CARDID是候选键。
补充说明:一个关系的候选键可以有多个。
(3)EMP_NO 或EMP_CARDID可选作本关系的主键。
补充说明:一个关系的候选键有多个,但主键只能有一个。通常在候选键中选一个作为主键。
(4)DEPT_NO为本关系相对于部门关系的外键。
理由:DEPT_NO在本关系中不是主键,而在部门关系中是主键,所以它是本关系的外键。
补充说明:外键的作用是进行连接操作。例如现在要查找某个职工所在的部门名称,我们就需要用到外键来与部门关系进行连接,连接之后可以得到职工所在部门的名称。
4.图示法求候选键
求关系模式的候选键是进行范式界定的基础 ,也是系统分析员应该掌握的基本技能。使用候选键的定义“如果一个属性集能唯一标识元组,且又不含有多余属性。”来求解一个简单关系模式的候选键尚能应对,但面对复杂一些的关系模式,这种方法就不管用了。在此,引入一种求候选键的快捷方法,即图示法。
使用图示法求候选键,主要有三个步骤:
(1)将关系的函数依赖关系,用“有向图”的方式表示。
(2)找出入度为0的属性,并以该属性集合为起点,尝试遍历有向图,若能正常遍历图中所有结点,则该属性集即为关系模式的候选键。
(3)若入度为0的属性集不能遍历图中所有结点,则需要尝试性的将一些中间结点(既有入度,也有出度的结点)并到入度为0的属性集中,直至该集合能遍历所有结点,集合为候选键。
例如,给定关系R(A1,A2,A3,A4)上的函数依赖集F={A1→A2,A3→A2,A2→A3,A2→A4},现在要求R的候选关键字。
第一步,需要针对函数依赖集画出有向图,如图5-4所示。图5-4函数依赖集对应有向图
第二步,从该图中找出入度为0的结点,本图中入度为0的结点只有1个,即A1。通过尝试,可以发现从A1出发可以遍历有向图中的所有结点,所以本关系模式的候选键为A1。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。