精华内容
下载资源
问答
  • 常见的关系数据库全收录)

    万次阅读 2018-07-25 15:58:45
    它采用标准的SQL结构化查询语言,支持多种数据类型,提供面向对象存储的数据支持,具有第四代语言开发工具,支持Unix、Windows NT、OS/2、Novell等多种平台。除此之外,它还具有很好的并行处理功...

    天子呼来不上船,自称臣是酒中仙。 —杜甫《饮中八仙歌》

    1.Oracle Oracle是1983年推出的世界上第一个开放式商品化关系型数据库管理系统。它采用标准的SQL结构化查询语言,支持多种数据类型,提供面向对象存储的数据支持,具有第四代语言开发工具,支持Unix、Windows NT、OS/2、Novell等多种平台。除此之外,它还具有很好的并行处理功能。Oracle产品主要由Oracle服务器产品、Oracle开发工具、Oracle应用软件组成,也有基于微机的数据库产品。主要满足对银行、金融、保险等企业、事业开发大型数据库的需求。
    2.SQL Server SQL即结构化查询语言(Structured Query Language,简称为SQL)。SQL Server最早出现在1988年,当时只能在OS/2操作系统上运行。2000年12月微软发布了SQL Server 2000,该软件可以运行于Windows NT/2000/XP等多种操作系统之上,是支持客户机/服务器结构的数据库管理系统,它可以帮助各种规模的企业管理数据。      随着用户群的不断增大,SQL Server在易用性、可靠性、可收缩性、支持数据仓库、系统集成等方面日趋完美。特别是SQL Server的数据库搜索引擎,可以在绝大多数的操作系统之上运行,并针对海量数据的查询进行了优化。目前SQL Server已经成为应用最广泛的数据库产品之一。      由于使用SQL Server不但要掌握SQL Server的操作,而且还要能熟练掌握Windows NT/2000 Server的运行机制,以及SQL语言,所以对非专业人员的学习和使用有一定的难度。
    3.Sybase 1987年推出的大型关系型数据库管理系统Sybase,能运行于OS/2、Unix、Windows NT等多种平台,它支持标准的关系型数据库语言SQL,使用客户机/服务器模式,采用开放体系结构,能实现网络环境下各节点上服务器的数据库互访操作。技术先进、性能优良,是开发大中型数据库的工具。Sybase产品主要由服务器产品Sybase SQL Server、客户产品Sybase SQL Toolset和接口软件Sybase Client/Server Interface组成,还有著名的数据库应用开发工具PowerBuilder。
    4.DB2 DB2是基于SQL的关系型数据库产品。20世纪80年代初期DB2的重点放在大型的主机平台上。到90年代初,DB2发展到中型机、小型机以及微机平台。DB2适用于各种硬件与软件平台。各种平台上的DB2有共同的应用程序接口,运行在一种平台上的程序可以很容易地移植到其他平台。DB2的用户主要分布在金融、商业、铁路、航空、医院、旅游等各个领域,以金融系统的应用最为突出。
    5.Access Access是在Windows操作系统下工作的关系型数据库管理系统。它采用了Windows程序设计理念,以Windows特有的技术设计查询、用户界面、报表等数据对象,内嵌了VBA(全称为Visual Basic Application)程序设计语言,具有集成的开发环境。Access提供图形化的查询工具和屏幕、报表生成器,用户建立复杂的报表、界面无需编程和了解SQL语言,它会自动生成SQL代码。      Access被集成到Office中,具有Office系列软件的一般特点,如菜单、工具栏等。与其他数据库管理系统软件相比,更加简单易学,一个普通的计算机用户,没有程序语言基础,仍然可以快速地掌握和使用它。最重要的一点是,Access的功能比较强大,足以应付一般的数据管理及处理需要,适用于中小型企业数据管理的需求。当然,在数据定义、数据安全可靠、数据有效控制等方面,它比前面几种数据库产品要逊色不少。
    6.MySql MySQL是一种开放源代码的关系型数据库管理系统(RDBMS),使用最常用的数据库管理语言–结构化查询语言(SQL)进行数据库管理。MySQL是开放源代码的,因此任何人都可以在General Public icense的许可下下载并根据个性化的需要对其进行修改。MySQL因为其速度、可靠性和适应性而备受关注。大多数人都认为在不需要事务化处理的情况下,MySQL是管理内容最好的选择。
    7.vfp Visual FoxPro ,是Microsoft公司从Fox公司的FoxBase数据库软件经过数次改良,并且移植到Windows之后,得来的应用程序开发软件,主要用于开发数据管理与运算等方面的软件。VFP是Microsoft公司推出的最新可视化数据库管理系统平台,是功能特别强大的32位数据库管理系统。它提供了功能完备的工具、极其友好的用户界面、简单的数据存取方式、独一无二的跨平台技术,具有良好的兼容性、真正的可编译性和较强的安全性,是目前最快捷、最实用的数据库管理系统软件之一。
    8.INGRES Ingres 是比较早的数据库系统,开始于加利福尼亚大学柏克莱分校的一个研究项目,该项目开始于 70 年代早期,在 80 年代早期结束。像柏克莱大学的其他研究项目一样,它的代码使用BSD许可证。从 80 年代中期,在Ingres 基础上产生了很多商业数据库软件,包括 Sybase、Microsoft SQL Server、NonStop SQL、Informix 和许多其他的系统。在 80 年代中期启动的后继项目 Postgres,产生了 PostgreSQL、Illustra,无论从任何意义上来说,Ingres 都是历史上最有影响的计算机研究项目之一。
    展开全文
  • 在本单元,你将了解一些最常见的关系数据库类型。 什么是 NoSQL? 阅读有关非关系数据库时,可能会看到术语“NoSQL”。 NoSQL 是一个相当宽泛的术语,仅表示非关系。 关于它是否意味着“不是 SQL”或“不仅仅...

    描述非关系数据库和 NoSQL 数据库的类型

    非关系数据是一个包罗万象的术语,是指任何不以一组表为结构的内容。 存在许多不同类型的非结构化数据,这些信息用于各种各样的目的。 因此,存在许多不同类型的非关系数据库管理系统,每一个系统都面向一组特定的方案。

    在本单元中,你将了解一些最常见的非关系数据库类型。

    什么是 NoSQL?

    阅读有关非关系数据库时,可能会看到术语“NoSQL”。 NoSQL 是一个相当宽泛的术语,仅表示非关系。 关于它是否意味着“不是 SQL”或“不仅仅是 SQL”,存在一些争论;一些非关系数据库支持适用于文档而非表的 SQL 版本(示例包括 Azure Cosmos DB)。

    NoSQL(非关系)数据库通常分为四个类别:键值存储、文档数据库、列系列数据库和图形数据库。 以下各节讨论这些类型的 NoSQL 数据库。

    什么是键值存储?

    键值存储是用于插入和查询数据的最简单(通常也是最快)的 NoSQL 数据库类型。 键值存储中的每个数据项都有两个元素:一个键和一个值。 键唯一标识项,而值保存项的数据。 值对数据库管理系统是不透明的。 项按键顺序进行存储。

     备注

    术语“不透明”表示数据库管理系统仅将值视为非结构化块。 只有应用程序可识别值中的数据结构以及其包含的字段。 与“不透明”相反的是“透明”。 如果数据是透明的,则数据库管理系统可识别字段在数据中的组织方式。 关系表是透明结构的示例。

    键值存储的示例

    查询指定用于标识要检索的项的键。 无法搜索值。 从键值存储中检索数据的应用程序负责分析返回的值的内容。

    写入操作仅限于插入和删除。 如果需要更新项,则必须检索该项,在内存中(在应用程序中)对其进行修改,然后将其写回到数据库,覆盖原始项(实际上是删除和插入)。

    键值存储的重点是能够非常快速地读取和写入数据。 搜索功能是次要的。 当大量数据以连续流的形式到达且必须立即存储时,键值存储是数据引入的极佳选择。

    Azure 表存储是键值存储的示例。 Cosmos DB 还可使用表 API 来实现键值存储。

    什么是文档数据库?

    文档数据库表示键值存储中 NoSQL 数据库的相反的一面。 在文档数据库中,每个文档都有唯一的 ID,但文档中的字段对数据库管理系统是透明的。 如上一单元所述,文档数据库通常以 JSON 格式存储数据,也可使用其他格式(例如 XML、YAML、JSON、BSON)对其进行编码。 文档甚至可以存储为纯文本。 文档中的字段向存储管理系统公开,使应用程序能够使用这些字段中的值查询和筛选数据。

    通常,文档包含实体的全部数据。 构成实体的项特定于应用程序。 例如,实体可以包含客户、订单或两者组合的详细信息。 单个文档可能包含将在 RDBMS(关系数据库管理系统)中跨多个关系表的信息。

    文档存储不要求所有文档都具有相同的结构。 这种自由格式的方法提供很大的灵活性。 随着业务需求的变化,应用程序可在文档中存储不同的数据。

    文档存储

    应用程序可以使用文档键来检索文档。 键是文档的唯一标识符。 一些文档数据库会自动创建文档键。 另一些文档数据库可指定要用作键的文档的属性。 应用程序还可根据一个或多个字段的值来查询文档。 一些文档数据库支持索引编制,以便基于一个或多个索引字段快速查找文档。

    一些文档数据库管理系统支持就地更新,使应用程序能够在不重写整个文档的情况下修改文档中特定字段的值。 另一些文档数据库管理系统(如 Cosmos DB)只能读取和写入整个文档。 在这些情况下,更新会用新版本替换整个文档。 这种方法有助于减少数据库中的碎片,从而可以提高性能。

    与关系数据库相比,大多数文档数据库将更快地引入大量数据,但对于此类处理来说,并不如键值存储那样理想。 文档数据库的重点是其查询功能。

    Azure Cosmos DB 在其 Core (SQL) API 中实现文档数据库方法。

    什么是列系列数据库?

    列系列数据库将数据组织成行和列。 此结构的示例包括 ORC 和 Parquet 文件,详见上一单元。

    在最简单的形式中,列系列数据库至少在概念上与关系数据库非常相似。 列系列数据库的真正强大之处在于其构造稀疏数据的非规范化方法。

    例如,如果需要在关系数据库中存储有关客户及其地址的信息(如上一部分所述,无需维护历史数据),则可以设计类似于下面所示的架构。 此图还显示了一些示例数据。 在此示例中,客户 1 和客户 3 共享同一地址,且架构确保此地址信息不重复。 这是实现一对多关系的标准方法。

    显示客户和地址的关系结构

    关系模型支持一种非常通用的方法来实现此类型的关系,但要查找任何给定客户的地址,应用程序需要运行联接两个表的查询。 如果这是应用程序执行的最常见的查询,则在存在大量请求且表本身很大的情况下,与执行此联接操作相关的开销会迅速增加。

    列系列数据库的目的是有效处理此类情况。 可以将列系列数据库视为包含行和列的表格数据,但能将这些列分为称为列系列的组。 每个列系列包含一组逻辑上相关的列。 下图显示了构造与上一幅图像相同信息的方法,即通过使用列系列数据库将数据分组为包含客户名称和地址信息的两个列系列。 还可通过其他方式组织列,但应实现列系列,以优化应用程序执行的最常见查询。 在这种情况下,检索客户地址的查询可以提取的数据比相应关系数据库中所需的读取次数少;这些查询可以直接从 AddressInfo 列系列中提取数据。

    列系列数据库的示例

    上面的插图是概念性的而不是物理的,旨在显示数据的逻辑结构,而不是物理上的组织方式。 列系列数据库中的每一行都包含一个键,可以使用此键来提取一行的数据。

    在大多数列系列数据库中,列系列是单独存储的。 在前面的示例中,CustomerInfo 列系列以简单的垂直分区形式保存在物理存储的一个区域中,而 AddressInfo 列系列则保存在另一区域中。 实际上应该根据列系列而不是行来考虑结构。 跨多个列系列的单个实体的数据在每个列系列中都具有相同的行键。 作为前面所示的概念布局的替代方法,可以将显示的数据可视化为以下一对物理结构。

    列系列数据库的物理结构

    列系列数据库管理系统使用得最广泛的是 Apache Cassandra。 Azure Cosmos DB 通过 Cassandra API 支持列系列方法。

    什么是图形数据库?

    利用图形数据库可以存储实体,但主要侧重于这些实体之间的关系。 图形数据库存储两种类型的信息:可视为实体实例的节点以及指定节点间关系的边缘。 节点和边缘都可以有提供有关该节点或边缘(例如表中的列)的信息的属性。 此外,边缘可以具有指示关系性质的方向。

    图形数据库的目的是使应用程序能够有效地执行遍历节点和边缘网络的查询,以及分析实体之间的关系。 下图显示了组织的人事数据库,其结构为图形。 实体是组织中的员工和部门,边缘表示汇报关系和员工所在的部门。 在此图中,边缘上的箭头表示关系的方向。

    图形存储

    此类结构使查询变得简单,如“找到直接或间接为 Sarah 工作的所有员工”或“谁与 John 在同一部门工作?” 对于具有大量实体和关系的大型图形,可以很快速地执行非常复杂的分析,并且许多图形数据库都可提供查询语言,用于有效遍历关系网络。 通常可以在关系数据库中存储相同的信息,但查询此信息所需的 SQL 可能需要许多昂贵的递归联接操作和嵌套的子查询。

    Azure Cosmos DB 使用 Gremlin API 支持图形数据库。 Gremlin API 是用于创建和查询图形的标准语言。

    展开全文
  • 常见的数据库

    2021-04-18 15:26:47
    DB2是关系型数据库平台,其采用多进程多线索的结构,支持多用户或应用程序在同一条SQL 语句查询不同数据库和数据。 PostgreSQL 是一个对象-关系数据库服务器,号称 “世界上先进开源关系型数据库”。 Hadoop是...

    SQL是用于访问和处理数据库的标准的计算机语言。

    MySQL是小型的开源的关系型数据库管理系统。

    SQL Server 是 Microsoft 开发的关系数据库管理系统。

    Oracle数据库系统是目前世界上流行的关系数据库管理系统。

    DB2是关系型数据库平台,其采用多进程多线索的结构,支持多用户或应用程序在同一条SQL 语句中查询不同数据库和数据。

    PostgreSQL 是一个对象-关系数据库服务器,号称 “世界上最先进的开源关系型数据库”。

    Hadoop是个很流行的分布式计算解决方案,Hive是基于hadoop的数据仓库工具,hive 构建在基于静态批处理的Hadoop 之上。

    GreenPlum采用了MPP(大规模并行处理),是一个由多个独立的数据库服务组合成关系型数据库集群。

    ECharts 是一个使用 JavaScript 实现的开源可视化库,涵盖各行业图表。

    R是一种集统计分析与图形显示为一体的统计分析软件,具有很强的互动性。

    python是一种跨平台的计算机程序设计语言,被广泛用于系统管理任务的处理和Web编程。

    展开全文
  • 实际上你可以把它粗略地理解为一张数据结构所符合某种设计标准级别。就像家里装修买建材,环保是E0级,其次是E1级,还有E2级等等。数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF。一般在我们设计...

    首先要明白”范式(NF)”是什么意思。
    按照教材中的定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。很晦涩吧?
    实际上你可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材,最环保的是E0级,其次是E1级,还有E2级等等。数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF。
    一般在我们设计关系型数据库的时候,最多考虑到BCNF就够。符合高一级范式的设计,必定符合低一级范式,例如符合2NF的关系模式,必定符合1NF。

    接下来就对每一级范式进行一下解释,首先是第一范式(1NF)

    符合1NF的关系(你可以理解为数据表。“关系模式”和“关系”的区别,类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例,你可以把”关系”理解为一张带数据的表,而“关系模式”是这张数据表的表结构。1NF的定义为:符合1NF的关系中的每个属性都不可再分表1所示的情况,就不符合1NF的要求。
    在这里插入图片描述
    表1

    实际上,1NF是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如SQL Server,Oracle,MySQL中创建数据表的时候,如果数据表的设计不符合这个最基本的要求,那么操作一定是不能成功的。也就是说,只要在RDBMS中已经存在的数据表,一定是符合1NF的。如果我们要在RDBMS中表现表中的数据,就得设计为表2的形式:
    在这里插入图片描述
    表2

    但是仅仅符合1NF的设计,仍然会存在数据冗余过大,插入异常,删除异常,修改异常的问题,例如对于表3中的设计:
    在这里插入图片描述

    表3

    1. 每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大
    2. 假如学校新建了一个系,但是暂时还没有招收任何学生(比如3月份就新建了,但要等到8月份才招生),那么是无法将系名与系主任的数据单独地添加到数据表中去的(注1)——插入异常
      注1:根据三种关系完整性约束中实体完整性的要求,关系中的码(注2)所包含的任意一个属性都不能为空,所有属性的组合也不能重复。为了满足此要求,图中的表,只能将学号与课名的组合作为码,否则就无法唯一地区分每一条记录。
      注2:码:关系中的某个属性或者某几个属性的组合,用于区分每个元组(可以把“元组”理解为一张表中的每条记录,也就是每一行)。
    3. 假如将某个系中所有学生相关的记录都删除,那么所有系与系主任的数据也就随之消失了(一个系所有学生都没有了,并不表示这个系就没有了)。——删除异常
    4. 假如李小明转系到法律系,那么为了保证数据库中数据的一致性,需要修改三条记录中系与系主任的数据。——修改异常。

    正因为仅符合1NF的数据库设计存在着这样那样的问题,我们需要提高设计标准,去掉导致上述四种问题的因素,使其符合更高一级的范式(2NF),这就是所谓的“规范化”。

    第二范式(2NF) 在关系理论中的严格定义我这里就不多介绍了(因为涉及到的铺垫比较多),只需要了解2NF对1NF进行了哪些改进即可。其改进是,2NF在1NF的基础之上,消除了非主属性对于码的部分函数依赖。接下来对这句话中涉及到的四个概念——“函数依赖”“码”“非主属性”、与**“部分函数依赖”**进行一下解释。

    函数依赖
    我们可以这么理解(但并不是特别严格的定义):若在一张表中,在属性(或属性组)X的值确定的情况下,必定能确定属性Y的值,那么就可以说Y函数依赖于X,写作 X → Y。也就是说,在数据表中,不存在任意两条记录,它们在X属性(或属性组)上的值相同,而在Y属性上的值不同。这也就是“函数依赖”名字的由来,类似于函数关系 y = f(x),在x的值确定的情况下,y的值一定是确定的。

    例如,对于表3中的数据,找不到任何一条记录,它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号,写作 学号 → 姓名。但是反过来,因为可能出现同名的学生,所以有可能不同的两条学生记录,它们在姓名上的值相同,但对应的学号不同,所以我们不能说学号函数依赖于姓名。表中其他的函数依赖关系还有如:

    • 系名 → 系主任
    • 学号 → 系主任
    • (学号,课名) → 分数

    但以下函数依赖关系则不成立:

    • 学号 → 课名
    • 学号 → 分数
    • 课名 → 系主任
    • (学号,课名) → 姓名

    从“函数依赖”这个概念展开,还会有三个概念:

    完全函数依赖

    在一张表中,若 X → Y,且对于 X 的任何一个真子集(假如属性组 X 包含超过一个属性的话),X ’ → Y 不成立,那么我们称 Y 对于 X 完全函数依赖,记作 X F→ Y。(那个F应该写在箭头的正上方,没办法打出来……,正确的写法如图1
    在这里插入图片描述
    图1

    例如:

    • 学号 F→ 姓名
    • (学号,课名) F→ 分数 (注:因为同一个的学号对应的分数不确定,同一个课名对应的分数也不确定)

    部分函数依赖

    假如 Y 函数依赖于 X,但同时 Y 并不完全函数依赖于 X,那么我们就称 Y 部分函数依赖于 X,记作 X P→ Y,如图2
    在这里插入图片描述
    图2

    例如:

    • (学号,课名) P→ 姓名

    传递函数依赖
    假如 Z 函数依赖于 Y,且 Y 函数依赖于 X (这里为:『Y 不包含于 X,且 X 不函数依赖于 Y』这个前提),那么我们就称 Z 传递函数依赖于 X ,记作 X T→ Z,如图3
    在这里插入图片描述
    图3


    设 K 为某表中的一个属性或属性组,若除 K 之外的所有属性都完全函数依赖于 K(这个“完全”不要漏了),那么我们称 K 为候选码,简称为码。在实际中我们通常可以理解为:假如当 K 确定的情况下,该表除 K 之外的所有属性的值也就随之确定,那么 K 就是码。一张表中可以有超过一个码。(实际应用中为了方便,通常选择其中的一个码作为主码

    例如:对于表3,**(学号、课名)**这个属性组就是码。该表中有且仅有这一个码。(假设所有课没有重名的情况)

    非主属性
    包含在任何一个码中的属性成为主属性。

    例如:
    对于表3,主属性就有两个,学号课名

    终于可以回过来看2NF了。首先,我们需要判断,表3是否符合2NF的要求?根据2NF的定义,判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在,则数据表最高只符合1NF的要求,若不存在,则符合2NF的要求。判断的方法是:

    第一步:找出数据表中所有的
    第二步:根据第一步所得到的码,找出所有的主属性
    第三步:数据表中,除去所有的主属性,剩下的就都是非主属性了
    第四步:查看是否存在非主属性对码的部分函数依赖

    对于表3,根据前面所说的四步,我们可以这么做:

    第一步:

    1. 查看所有每一单个属性,当它的值确定了,是否剩下的所有属性值都能确定。
    2. 查看所有包含有两个属性的属性组,当它的值确定了,是否剩下的所有属性值都能确定。
    3. ……
    4. 查看所有包含了六个属性,也就是所有属性的属性组,当它的值确定了,是否剩下的所有属性值都能确定。

    看起来很麻烦是吧,但是这里有一个诀窍,就是假如A是码,那么所有包含了A的属性组,如(A,B)、(A,C)、(A,B,C)等等,都不是码了(因为作为码的要求里有一个“完全函数依赖”)。图4表示了表中所有的函数依赖关系:

    图4表示了表中所有的函数依赖关系:
    在这里插入图片描述
    图4

    这一步完成以后,可以得到,表3的码只有一个,就是(学号、课名)。

    第二步:
    主属性有两个:学号课名

    第三步:
    非主属性有四个:姓名、系名、系主任、分数

    第四步:
    对于(学号,课名) → 姓名,有 学号 → 姓名,存在非主属性 姓名 对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系名,有 学号 → 系名,存在非主属性 系名 对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系主任,有 学号 → 系主任,存在非主属性 系主任 对码(学号,课名)的部分函数依赖。

    所以表3存在非主属性对于码的部分函数依赖,最高只符合1NF的要求,不符合2NF的要求。

    为了让表3符合2NF的要求,我们必须消除这些部分函数依赖,只有一个办法,就是将大数据表拆分成两个或者更多个更小的数据表,在拆分的过程中,要达到更高一级范式的要求,这个过程叫做”模式分解“。模式分解的方法不是唯一的,以下是其中一种方法:选课(学号,课名,分数)
    学生(学号,姓名,系名,系主任)

    我们先来判断以下,选课表学生表,是否符合了2NF的要求?

    对于选课表,其码是(学号,课名),主属性是学号课名,非主属性是分数学号确定,并不能唯一确定分数课名确定,也不能唯一确定分数,所以不存在非主属性分数对于码 (学号,课名)的部分函数依赖,所以此表符合2NF的要求。

    对于学生表,其码是学号,主属性是学号,非主属性是姓名系名系主任,因为码只有一个属性,所以不可能存在非主属性对于码 的部分函数依赖,所以此表符合2NF的要求。

    图5表示了模式分解以后的新的函数依赖关系
    在这里插入图片描述
    图5

    表4表示了模式分解以后新的数据
    在这里插入图片描述
    表4

    (这里还涉及到一个如何进行模式分解才是正确的知识点,先不介绍了)

    现在我们来看一下,进行同样的操作,是否还存在着之前的那些问题?

    1. 李小明转系到法律系
      只需要修改一次李小明对应的系的值即可。——有改进
    2. 数据冗余是否减少了?
      学生的姓名、系名与系主任,不再像之前一样重复那么多次了。——有改进
    3. 删除某个系中所有的学生记录
      该系的信息仍然全部丢失。——无改进
    4. 插入一个尚无学生的新系的信息。
      因为学生表的码是学号,不能为空,所以此操作不被允许。——无改进

    所以说,仅仅符合2NF的要求,很多情况下还是不够的,而出现问题的原因,在于仍然存在非主属性系主任对于码学号的传递函数依赖。为了能进一步解决这些问题,我们还需要将符合2NF要求的数据表改进为符合3NF的要求。

    第三范式(3NF)
    3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。也就是说, 如果存在非主属性对于码的传递函数依赖,则不符合3NF的要求。

    接下来我们看看表4中的设计,是否符合3NF的要求。

    对于选课表,主码为(学号,课名),主属性为学号课名,非主属性只有一个,为分数,不可能存在传递函数依赖,所以选课表的设计,符合3NF的要求。

    对于学生表,主码为学号,主属性为学号,非主属性为姓名系名系主任。因为 学号 → 系名,同时 系名 → 系主任,所以存在非主属性系主任对于码学号的传递函数依赖,所以学生表的设计,不符合3NF的要求。

    为了让数据表设计达到3NF,我们必须进一步进行模式分解为以下形式:
    选课(学号,课名,分数)
    学生(学号,姓名,系名)
    系(系名,系主任)

    对于选课表,符合3NF的要求,之前已经分析过了。

    对于学生表,码为学号,主属性为学号,非主属性为系名,不可能存在非主属性对于码的传递函数依赖,所以符合3NF的要求。

    对于系表,码为系名,主属性为系名,非主属性为系主任,不可能存在非主属性对于码的传递函数依赖(至少要有三个属性才可能存在传递函数依赖关系),所以符合3NF的要求。

    新的函数依赖关系如图6
    在这里插入图片描述
    图6

    新的数据表如表5
    在这里插入图片描述
    表5

    现在我们来看一下,进行同样的操作,是否还存在着之前的那些问题?

    1. 删除某个系中所有的学生记录
      该系的信息不会丢失。——有改进
    2. 插入一个尚无学生的新系的信息。
      因为系表与学生表目前是独立的两张表,所以不影响。——有改进
    3. 数据冗余更加少了。——有改进

    结论
    由此可见,符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题。当然,在实际中,往往为了性能上或者应对扩展的需要,经常 做到2NF或者1NF,但是作为数据库设计人员,至少应该知道,3NF的要求是怎样的。

    =====================================================================
    BCNF范式

    要了解 BCNF 范式,那么先看这样一个问题:

    若:

    1. 某公司有若干个仓库;
    2. 每个仓库只能有一名管理员,一名管理员只能在一个仓库中工作;
    3. 一个仓库中可以存放多种物品,一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。

    那么关系模式 仓库(仓库名,管理员,物品名,数量) 属于哪一级范式?

    答:已知函数依赖集:仓库名 → 管理员,管理员 → 仓库名,(仓库名,物品名)→ 数量码:(管理员,物品名),(仓库名,物品名)主属性:仓库名、管理员、物品名非主属性:数量
    ∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。
    ∴ 此关系模式属于3NF。

    基于此关系模式的关系(具体的数据)可能如图所示:

    在这里插入图片描述
    好,既然此关系模式已经属于了 3NF,那么这个关系模式是否存在问题呢?我们来看以下几种操作:

    1. 先新增加一个仓库,但尚未存放任何物品,是否可以为该仓库指派管理员?——不可以,因为物品名也是主属性,根据实体完整性的要求,主属性不能为空。
    2. 某仓库被清空后,需要删除所有与这个仓库相关的物品存放记录,会带来什么问题?——仓库本身与管理员的信息也被随之删除了。
    3. 如果某仓库更换了管理员,会带来什么问题?——这个仓库有几条物品存放记录,就要修改多少次管理员信息。

    从这里我们可以得出结论,在某些特殊情况下,即使关系模式符合 3NF 的要求,仍然存在着插入异常,修改异常与删除异常的问题,仍然不是 ”好“ 的设计。

    造成此问题的原因:存在着主属性对于码的部分函数依赖与传递函数依赖。(在此例中就是存在主属性【仓库名】对于码【(管理员,物品名)】的部分函数依赖。

    解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

    仓库(仓库名,管理员)
    库存(仓库名,物品名,数量)

    这样,之前的插入异常,修改异常与删除异常的问题就被解决了。

    以上就是关于 BCNF 的解释。

    =====================================================================
    典型习题及其解答

    问题1:

    李德竹 :老师您好,我看了您关于数据库范式的回答,有一点不太理解,就是关于码的
    定义,如果除K之外的所有属性都完全函数依赖于K时才能称K为码,那么在判断2NF时又怎么会存在非主属性对码的部分函数依赖这种情况?希望老师有时间能指点一下,谢谢

    我 :在“码”的定义中,除 K 之外的所有属性应该看成是一个集合 U(也就是一个整体),也就是说,只有 K 能够完全函数决定 U 中的每一个属性,那么 K 才是码。如果 K 只是能够完全函数决定 U 中的一部分属性,而不能完全函数决定另外一部分属性,那么 K 不是码。

    比如有关系模式 R (Sno, Sname, Cno, Cname, Sdept, Sloc, Grade),其中函数依赖集为 F= {Sno → Sname, Sno → Sdept, Sdept → Sloc,Sno → Sloc, Cno → Cname, (Sno, Cno) → Grade }

    那么 R 中的码只能是 (Sno, Cno),Sno 或 Cno 并不能完全函数决定除 Sno / Cno 之外的所有其他属性(其实就是不能决定 Grade ),所以单独的 Sno 与 Cno 并不能作为码。

    所以可得到主属性:Sno, Cno
    非主属性:Sname, Cname, Sdept, Sloc, Grade

    R 中存在非主属性 Cname 对于码 (Sno, Cno) 的部分函数依赖 (Cno → Cname) 。(还有很多别的例子就不一一列举了)。所以 R 不符合 2NF 的要求。

    作者:刘慰老师
    链接:https://www.zhihu.com/question/24696366/answer/29189700

    展开全文
  • 树形数据关系数据库的存储

    千次阅读 2014-03-25 15:34:34
    树形数据关系数据库中的存储同对象一样,都会遇到一个"阻抗不匹配"问题。如何设计一个表结构,才能较好满足需求呢?事实上,有很多解决方案,但是没有哪一种是放之四海而皆准。我个人认为解决方案选择,...
  • 什么是数据库数据库(Database)是按照数据结构来组织...在当今的互联网最常见的数据库模型主要是两种,即关系数据库和非关系数据库关系数据库比较 非关系数据库比较 下面看看一些常用的...
  • 数据是架构的中心,程序 = 算法 + 数据结构,那么系统 = 业务逻辑 x 数据。可以说很多架构问题都是出在数据层,例如常见的「烟囱式系统」带来的种种问题,特别是数据孤岛问题,其实本质上的原因就出在没有将数据层...
  • 常见的NoSQl数据库

    2021-04-21 22:26:51
    关系数据库是主流的数据存储形式,曾作为数据持久化领域的唯一可选方案,但是现在有多种不同的数据库,每一种都代表了不同形式的数据,并提供了适应多种领域模型的功能。 MongoDB:流行的开源文档数据库之一 ...
  • 在当今的互联网最常见的数据库模型主要是两种,即关系数据库和非关系数据库数据库分类 〓关系数据库介绍〓 1、关系数据库的由来 虽然网状数据库和层次数据库已经很好的解决了数据...
  • 首先我们要了解是,数据库与集合只有在插入数据的时候才会被正真创建,否则不会真正创建MongoDB数据库是非关系的数据库,也是关系数据库的关系数据库,可以理解成介于Mysql(表结构)与Redis...
  • 数据库常见的面试题=

    2017-11-20 16:42:39
    是对关系数据库最基本要求。如果不满足第一范式,就不能称之为关系数据库。 如果仅仅满足第一范式:仍然会存在,数据冗余,增加、删除、修改异常。 第二范式:建立再第一范式基础上。非主属性,对于
  • 并且,最终说来,产生价值的并不是绚丽的界面和现代化的输入方式,而是存放在数据库中的数据。不幸的是,虽然关系型数据库历经了约30年的发展,有成熟的理论和大量的实践基础,但是,大多数设计、开发人员在设计...
  • 并且,最终说来,产生价值的并不是绚丽的界面和现代化的输入方式,而是存放在数据库中的数据。不幸的是,虽然关系型数据库历经了约30年的发展,有成熟的理论和大量的实践基础,但是,大多数设计、开发人员在设计...
  • 数据 (metadata) 最常见的定义为“有关数据结构数据”,或者再简单一点就是“关于数据的信息”,日常生活的图例、图书馆目录卡和名片等都可以看作是元数据。在关系数据库管理系统 (DBMS) ,元数据描述了...
  • 所谓关系数据库,简单理解就是数据是有行和列两个维度组成数据集合,是根据数学集合思想演变而来关系数据库的特点就是数据呈现都是结构数据,也就是标准二维数据,使用结构化查询语句,也就是SQL...
  • 数据库

    2020-07-02 19:15:26
    一、数据库简介 数据库:就是数据的仓库,它是长期存储在计算机内,有组织的、可共享的数据的集合。...而在当今的互联网最常见的数据库模型主要是两种,即关系数据库(SQL)和非关系数据库(NoSQL,Not O...
  • 数据(metadata)最常见的定义为“有关数据结构数据”,或者再简单一点就是“关于数据的信息”,日常生活的图例、图书馆目录卡和名片等都可以看作是元数据。在关系型数 据库管理系统(DBMS),元数据描述了数据...
  • 对象/关系数据库映射(object/relational mapping (ORM))这个术语表示一种技术,用来把对象模型表示对象映射到基于SQL关系模型数据结构中去。 NHibernate不仅仅管理.NET类到数据库表映射(包括.NET数据类型到...
  • 一点警示:如果你是计算机专业,正好在学诸如数据库系统概论,操作系统,数据结构与算法之类课程,那么很诚恳建议你,不管它有多枯燥,能务必认真学习。血教训。 数据库分类 当今互联网,通常把数据库...
  •  元数据 (metadata) 最常见的定义为"有关数据结构数据",或者再简单一点就是"关于数据的信息",日常生活的图例、图书馆目录卡和名片等都可以看作是元数据。在关系数据库管理系统 (DBMS) ,元数据描述了数据...
  • 数据简介元数据 (metadata) 最常见的定义为“有关数据结构数据”,或者再简单一点就是“关于数据的信息”,日常生活的图例、图书馆目录卡和名片等都可以看作是元数据。在关系数据库管理系统 (DBMS) ,元数据...
  • 在当今的互联网最常见的数据库模型主要是两种,即关系数据库和非关系数据库。 列举如下常见的数据库 关系数据库: Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL 非关系数据库: ...
  • 表Table是数据库中数据存储最常见和最简单的一种形式数据库可以将复杂的数据结构用较为简单的二维表来表示二维表是由行和列组成的分别都包含着数据; 每个表都是由若干行和列组成的在数据库中表中的行被称为记录表中...
  • 使用RDBMS时,最常见的系统结构就是客户端/服务器类型(c/s类型) 服务器:用来接收其他程序发出的请求,并对该请求进行相应处理的程序(软件),或者是安装了此类程序的设备(计算机) 客户端:像服务器发出请求的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 495
精华内容 198
关键字:

关系数据库中最常见的数据结构是

数据结构 订阅