- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
2.1 数据模型 1. 层次数据模型 2. 网状数据模型 3. 关系数据模型 满足一定条件的二维表格 它的每一行是惟一的 每一列也是惟一的 如表2.1所示 2.2 关系模型的数据结构 1.关系(relation):一个二维表格。 2.属性(attribute):每一列 3.元组(tuple):每一行 4.域(domain):每一属性的取值范围 2.2 关系模型的数据结构 5.关键字(key):又称主属性 ⑴ 候选关键字 (candidate key) 惟一地标识一个元组的一个属性或多个属性的组合(且不含有多余属性) 。一个关系中可以有多个候选关键字。例如,“学号” ,“身份证号” 都可以作“学生” 的候选关键字。 ⑵ 主关键字(primary key) 把关系中的一个候选关键字定义为主关键字。一个关系中只能有一个主关键字,用以惟一地标识元组,简称为主键。 2.2 关系模型的数据结构 6.外键(foreign key) 如果某个关系中的一个属性或属性组合不是所在关系的主关键字或候选关键字,但却是其他关系的主关键字,对这个关系而言,称其为外部关键字,简称外键。 7.关系模式(relational schema) 关系模式是对关系数据结构的描述。 简记为:关系名(属性1,属性2,属性3,……属性n)。 关系模型 码是关系中重要的概念,它包括 超码:能够唯一识别元组的属性集 候选码:如果一个属性或属性集能够唯一标识元组,且又不含有多余的属性或属性集,则该属性或属性集则称为该关系模式的候选码 主码:在一个关系模式中,正在使用的候选码或由用户特别指定的某一候选码,可称为关系模式的主码 外码:如果关系R中某个属性或属性集是其他关系模式的主码,那么该属性或属性集是R的外码 在一个关系模式中,可以有多个候选码,可从多个候选码中选出一个作为关系的主码。一个关系模式最多只能有一个主码 基本概念的比较 2.3 关系数据库 以关系模型为基础的数据库,利用关系描述现实世界中的对象。 一个关系既可用来描述一个实体及其属性,也可用来描述实体间的联系。 关系数据库是由一组关系组成的,针对一个具体问题,应该如何构造一个适合于它的数据模式,即应该构造几个关系?每个关系由那些属性组成?这就是关系数据库逻辑设计要研究的问题。 2.3.2 关系数据库规范化 关系数据库规范化(Normal Form)的目的是建立正确、合理的关系,规范化的过程是一个分析关系的过程。 1.函数依赖及其对关系的影响 函数依赖是属性之间的一种联系,普遍存在于现实生活中。例如,银行通过客户的存款帐号,可以查询到该帐号的余额。又例如,表2-3是描述学生情况的关系(二维表格),用一种称为关系模式的形式表示为: STUDENT1(学号,姓名,性别,出生日期,专业) 由于每个学生有惟一的学号,一个学号只对应一位学生,一个学生只就读于一个专业,因此当学号的值确定之后,姓名及其所就读专业的值也就被唯一地确定了。属性间的这种依赖关系类似于数学中的函数。因此称账号函数决定账户余额,或者称账户余额函数地依赖于账号;学号函数决定姓名和专业,或者说姓名和专业函数依赖于学号,记作:学号→姓名,学号→专业;同样有学号→性别,学号→出生日期。 如果在关系STUDENT1的基础上增加一些信息,例如学生的“学院”及“院长”信息,有可能设计出如下关系模式: STUDENT2(学号,姓名,性别,出生日期,专业,学院,院长)。 函数依赖关系是:学号→学院、学院→院长。 表2.4 STUDENT2关系 数据库设计中的问题 数据冗余 例如院长的姓名会重复出现,重复的次数与该学院学生的个数相同。 更新异常 例如某学院更换院长后,系统必须修改与该学院学生有关的每一个元组。 插入异常 如果一个学院刚成立,尚无学生,则这个学院及其院长的信息就无法存入数据库。 删除异常 如果某个学院的学生全部毕业了,在删除该学院学生信息的同时,也把这个学院的信息(学院名称和院长)全部删除了。 2.规范化的本质 每个规范化的关系只有一个主题。如果某个关系有两个或多个主题,就应该分解为多个关系,每个关系只能有一个主题。规范化的过程就是不断分解关系的过程。 人们每发现一种异常,就研究一种规则防止异常出现。由此设计关系的准则得以不断改进。70年代初期,研究人员系统地定义了第一范式(Fist Normal Forms, 1NF),第二范式(Second Normal Form,2NF)和第三范式(Third Normal Form,3NF)。之后人们又定义了多种范式,但大多数简单业务数据库设计中只需要考虑第一范式、第二范式和第三范式。每种范式自动包含其前面的范式,各
文档评论(0)