-
2020-01-03 09:42:36
1. 多值依赖
1.1 多值依赖:多值依赖属4nf的定义范围,比函数依赖要复杂得多。在关系模式中,函数依赖不能表示属性值之间的一对多联系,这些属性之间有些虽然没有直接关系,但存在间接的关系,把没有直接联系、但有间接的联系称为多值依赖的数据依赖。
在函数依赖中,X与Y是否存在函数依赖关系,只需考察X,Y的两组属性,与别的属性无关。而在多值依赖中,X与Y是否存在多值依赖还需看属性Z。
1.2 数学定义:设R(U)是属性集U上的一个关系模式。X,Y,Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立,当且仅当对R(U)的任一关系r,给定的一对(x,z)值有一组Y的值,这组值仅仅决定于x值而与z值无关。
1.3 特点:1.允许X的一个值决定Y的一组值,这种决定关系与Z取值无关。
2.多值依赖是全模式的依赖关系。(多值依赖的缺点是:数据冗余太大)
1.4 举例:有这样一个关系 <仓库管理员,仓库号,库存产品号> ,假设一个产品只能放到一个仓库中,但是一个仓库可以有若干管理员,那么对应于一个 <仓库管理员,库存产品号>有一个仓库号,而实际上,这个仓库号只与库存产品号有关,与管理员无关,就说这是多值依赖。
2. 第四范式
2.1 数学定义:设关系R(X,Y,Z),其中X,Y,Z是成对的、不相交属性的集合。若存在非平凡多值依赖,则意味着对R中的每个属性Ai(i-1,2,...,n)存在有函数依赖X->Ai(X必包含键)。那么R∈4NF。
2.2 思想来源:1.第四范式是在关系数据库中,对关系的最基本要求的满足第一范式。这样的关系模式是合法的,允许的。但人们发现有些关系模式存在插入、删除、修改异常、数据冗余等弊病,人们寻求解决这些问题的方法,这就是规范化的目的。
2.规范化的基本思想是逐步消除数据依赖中不合适的部分,使关系数据库模式的各关系模式达到某种程度的“分离”,即“一事一地”的模式设计原则。
3.定义对解:定义和实例对比解析
3.1 多值依赖:设R(U)是属性集U上的一个关系模式。X,Y,Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立,当且仅当对R(U)的任一关系r,给定的一对(x,z)值有一组Y的值,这组值仅仅决定于x值而与z值无关
产品(X) 代理商(Y) 工厂(Z) Car A1 F1 Car A1 F2 Bus A2 F2 这里“产品(X)→→代理商(Y)”,产生的多值依赖关系如下
产品(X) 工厂(Z) 代理商(Y) Car F1 A1 Car F2 A1 这里一个car对应一组代理商,这就是代理商多值依赖于产品。为什么会产生这个多值依赖呢?
因为工厂,只有代理商A1销售Car ,但是这里却又两个工厂生产Car ,说以导致了Car和A1的关系冗余。这就是数据表的设计问题的体现。消除多值依赖也很简单。做如下表设计。产品-经销商关系表
产品 供应商 Car A1 Bus A1 Car A2 产品生产关系表
产品 工厂 Car F1 Car F2 Bus F2 3.2 从是否符合第四范式的角度分析以上表:设关系R(X,Y,Z),其中X,Y,Z是成对的、不相交属性的集合。若存在非平凡多值依赖,则意味着对R中的每个属性Ai(i-1,2,...,n)存在有函数依赖X->Ai(X必包含键)。那么R∈4NF。
产品(X) 代理商(Y) 工厂(Z) Car A1 F1 Car A1 F2 Bus A2 F2 “R中的每个属性Ai(i-1,2,...,n)存在有函数依赖X→Ai(X必包含键) ”,将这个要求,针对当前表展开。
X→Y:代理商依赖于产品
X→Z:工厂依赖于产品
从形式上看,这里明显Car → A1的关系有两个,不满足条件。这个是从数学上形式的分析,不符合第四范式。至于原因,就是上面多值依赖的存在。
更多相关内容 -
深入理解NPM依赖模型
2018-09-15 20:30:05即便是强大如Bower这样可以管理前端所有文件的工具也被推到了一边,对我来说最有趣的是npm相对新颖的依赖管理方法。不幸的是,根据我的经验,它实际上并没有那么好理解,所以我尝试在这里澄清它是如何工作的,以及它...npm是目前前端开发领域最主流的包管理器。虽然有其他选择,但npm的江湖地位短期内已经无法撼动。即便是强大如Bower这样可以管理前端所有文件的工具也被推到了一边,对我来说最有趣的是npm相对新颖的依赖管理方法。不幸的是,根据我的经验,它实际上并没有那么好理解,所以我尝试在这里澄清它是如何工作的,以及它如何影响用户或包开发者的。
基础回顾
站在较高的层次上来说,npm与其他编程语言的包管理器并没有太大不同:包依赖于其他包,它们用版本范围表示这些依赖关系。npm碰巧使用semver版本控制方案来表达这些范围,但它执行版本解析的方式大多不重要; 重要的是包可以依赖于范围而不是特定版本的包。
这在任何生态系统中都非常重要,因为将库锁定到一组特定的依赖项可能会导致严重的问题,但与其他类似的软件包系统相比,它在npm的情况下实际上要少得多。实际上,对于库作者来说,将依赖关系固定到特定版本而不影响依赖包或应用程序通常是安全的。棘手的一点是确定何时这是安全的,什么时候不安全,这就是我经常发现人们出错的原因。
重复依赖和依赖树
npm的大多数用户(或者至少是大多数软件包作者)最终都知道,与其他软件包管理器不同,npm安装了一个依赖树。也就是说,每个安装的软件包都有自己的一组依赖项,而不是强制每个软件包共享相同的规范软件包。显然,现在几乎每个包管理器都必须在某个时刻对依赖树进行建模,因为这就是程序员表达依赖关系的方式。
例如,考虑两个包,foo 和 bar。 它们中的每一个都有自己的依赖项集,可以表示为树:
foo ├── hello ^0.1.2 └── world ^1.0.7 bar ├── hello ^0.2.8 └── goodbye ^3.4.0
想象一下依赖于foo和bar的应用程序。显然,world 和 goodbye 的依赖关系完全不相关,所以npm如何处理它们相对无趣。 但是,请考虑hello的情况:两个包都需要冲突的版本。
大多数软件包管理器(包括RubyGems/Bundler,pip和Cabal)都会在这里进行barf,报告版本冲突。这是因为,在大多数软件包管理模型中,一次只能安装任何特定软件包的一个版本。 从这个意义上说,软件包管理器的主要职责之一是找出一组将同时满足每个版本约束的软件包版本。
相比之下,npm有一个更容易的工作:它完全可以安装同一个包的不同版本,因为每个包都有自己的依赖集。在前面提到的示例中,生成的目录结构如下所示:
node_modules/ ├── foo/ │ └── node_modules/ │ ├── hello/ │ └── world/ └── bar/ └── node_modules/ ├── hello/ └── goodbye/
值得注意的是,目录结构非常接近实际的依赖树。上面的图是一个简化:在实践中,每个传递依赖都有自己的node_modules目录,依此类推,但目录结构很快就会变得非常混乱。(此外,npm 3执行一些优化以尝试在可能的情况下共享依赖关系,但最终不需要实际理解模型)
当然,这个模型非常简单。显而易见的效果是每个软件包都有自己的小沙箱,对于像ramda,lodash或underscore这样的实用程序库来说,它非常出色。如果foo取决于ramda@^0.19.0但是bar取决于ramda@^0.22.0,它们可以完全和平共存而没有任何问题。
乍一看,只要底层运行时支持所需的模块加载方案,该系统显然优于替代的平面模型。然而,它并非没有缺点。
最明显的缺点是代码大小显着增加,因为同一个软件包的许多副本可能具有不同的版本。代码大小的增加通常意味着不仅仅是一个更大的程序 - 它可以对性能产生重大影响。较大的程序不能轻易地适应CPU缓存,只需要一些缓存页的写入和读取就可以显著降低速度。然而,这主要只是一种权衡,因为你牺牲了性能,而不是程序的正确性。
更加隐蔽的问题(以及我在npm生态系统中看到的那个没有太多考虑的问题)是依赖隔离如何影响跨包通信。
依赖性隔离和传递包边界的值
使用ramda的早期示例是npm的默认依赖关系管理方案真正可圈可点的地方,因为Ramda只提供了一堆简单的函数。通过这些是完全无害的。事实上,两个不同版本的Ramda混合功能将是完全可以的!不幸的是,并非所有情况都如此简单。
考虑一下React,React组件通常不是普通的旧数据;它们是复杂的值,可以通过各种方式进行扩展,实例化和呈现。React使用内部私有格式表示组件结构和状态,使用精心安排的键和值的混合以及JavaScript的对象系统的一些更强大的功能。这个内部结构可能会在React版本之间发生很大的变化,因此使用react@0.3.0定义的React组件可能无法正常使用react@15.3.1。
考虑到这一点,请考虑两个包定义自己的React组件并将其导出供消费者使用。查看它们的依赖树,我们可能会看到如下内容:
awesome-button └── react ^0.3.0 amazing-modal └── react ^15.3.1
鉴于这两个软件包使用了非常不同的React版本,npm将根据请求为每个软件包提供自己的React副本,并且可以愉快地安装软件包。但是,如果您尝试将这些组件一起使用,它们根本不起作用!较新版本的React根本无法理解旧版本的组件,因此您可能会遇到运行时错误,这些错误信息往往莫名其妙。
什么地方出了错?好吧,当包的依赖性纯粹是实现细节时,依赖性隔离很有效,这些细节从外部是感知不到的。但是,只要包的依赖性作为其接口的一部分公开,依赖性隔离不仅会出现细微错误,而且会在运行时导致完全失败。在传统的依赖关系管理下,这种情况要好得多,他们会在你尝试安装两个他们不能一起工作的软件包时告诉你,而不是等着你自己解决这个问题。
这可能听起来不是太糟糕 - 毕竟,JavaScript是一种非常动态的语言,所以静态的形式保证可用性几乎都很少,而且如果出现这些问题,你的测试应该能够捕获这些问题 - 但是当两个软件包在理论上可以一起工作很好时,它会导致不必要的问题,但是因为npm为每个人分配了一个特定包的副本(也就是说,它不够聪明,弄清楚它可以给他们两个相同的副本),所以事情就会崩溃。
特别是在npm之外看,并且在应用于其他语言时考虑这个模型,这一点越来越明显,这是行不通的。这篇博客文章的灵感来自一个讨论应用于Haskell的npm模型的Reddit线程,这个漏洞被吹捧为它无法用于这种静态语言的原因。
由于JavaScript生态系统的发展方式,大多数人都可以较为轻松地摆脱这种不正确行为所带来的潜在问题,而不引入任何新的问题。具体来说,JavaScript倾向于依赖duck类型而不是像instanceof这样的更严格的检查,因此满足相同协议的对象仍然是兼容的,即使它们的实现不完全相同。 但是,npm实际上为这个问题提供了一个强大的解决方案,允许包作者明确表达这些“跨接口”依赖关系。
对等依赖
通常,npm包依赖项列在包的package.json文件中的“dependencies”键下。但是,有一个名为“peerDependencies”的另一个较少使用的密钥,其格式与普通依赖项列表相同。区别在于npm如何执行依赖项解析:包不是获取自己的对等依赖项副本,而是期望依赖项由其依赖项提供。
这实际上意味着使用像Bundler和Cabal这样的工具使用的“传统”依赖解析机制有效地解决了对等依赖:必须有一个满足每个人约束的规范版本。从npm 3开始,事情就不那么简单了(具体来说,除非依赖包明确地依赖于对等包本身,否则不会自动安装对等依赖关系),但基本思想是相同的。这意味着包作者必须为他们安装的每个依赖项做出选择:它应该是普通依赖还是对等依赖?
这是我认为人们往往会有点疑惑的地方,即使是那些熟悉对等依赖机制的人。幸运的是,答案相对简单:在程序包可见的任何位置都可以看到有问题的依赖项?
这有时很难在JavaScript中看到,因为“类型”是不可见的; 也就是说,它们是动态的,很少明确地写出来。但是,仅仅因为类型是动态的并不意味着它们在运行时(并且在各种程序员的头脑中)不存在,所以规则仍然成立:如果包的公共接口中的函数类型以某种方式依赖于依赖性,它应该是对等依赖。
为了使这更具体一点,让我们看几个例子。 首先,让我们看看一些简单的案例,从ramda的一些用法开始:
import { merge, add } from 'ramda' export const withDefaultConfig = (config) => merge({ path: '.' }, config) export const add5 = add(5)
这里的第一个例子非常明显:在withDefaultConfig中,merge纯粹用作实现细节,因此它是安全的,并且它不是模块接口的一部分。 在add5中,这个例子有点棘手:add(5)的结果是由Ramda创建的部分应用函数,所以从技术上讲,Ramda创建的值是该模块接口的一部分。但是,add5与外界的合约只是它是一个JavaScript函数,它的参数增加了五个,并且它不依赖于任何特定于Ramda的功能,所以ramda可以安全地成为非同类依赖。
现在让我们看一下使用jpeg图像库的另一个例子:
import { Jpeg } from 'jpeg' export const createSquareBuffer = (size, cb) => createSquareJpeg(size).encode(cb) export const createSquareJpeg = (size) => new Jpeg(Buffer.alloc(size * size, 0), size, size)
在这种情况下,createSquareBuffer函数使用普通的Node.js Buffer对象调用回调,因此jpeg库是一个实现细节。如果这是该模块公开的唯一函数,则jpeg可以安全地成为非对等依赖项。但是,createSquareJpeg函数违反了该规则:它返回一个Jpeg对象,该对象是一个不透明的值,其结构由jpeg库专门定义。 因此,具有上述模块的包必须将jpeg列为对等依赖项。
这种限制也是相反的。例如,请考虑以下模块:
import { writeFile } from 'fs' export const writeJpeg = (filename, jpeg, cb) => jpeg.encode((image) => fs.writeFile(filename, image, cb))
上面的模块甚至没有导入jpeg包,但它隐含地依赖于Jpeg接口的encode方法。因此,尽管在代码中的任何地方都没有明确地使用它,但是包含上述模块的包应该包括jpeg作为对等依赖。
关键是要仔细考虑您的模块与其依赖的交互细节。如果这些交互以任何方式涉及其他包,则它们应该是对等依赖关系。如果他们不这样做,他们应该是普通的依赖。
将npm模型应用于其他语言
包管理的npm模型比其他语言更复杂,但它提供了一个真正的优势:实现细节保留为实现细节。在其他系统中,当你个人知道包管理器报告的版本冲突不是真正的问题,但是因为包系统必须选择一个规范版本时,很有可能发现自己处于“依赖地狱”中,没有办法在不调整依赖项中的代码的情况下取得进展。这非常令人沮丧。
这种依赖性隔离并不是现有的最先进的包管理形式 - 实际上远非如此 - 但它肯定比其他大多数主流系统更强大。当然,大多数其他语言只是通过更改包管理器就无法采用npm模型:拥有全局包命名空间可以防止在运行时级别安装同一包的多个版本。npm能够做它的功能是因为Node本身支持它。
也就是说,对等和非对等依赖之间的二分法有点令人困惑,特别是对于不是包作者的人。弄清楚哪个包需要进入哪个组并不总是明显或微不足道的。幸运的是,其他语言也许可以提供帮助。
返回Haskell,其强大的静态类型系统可能会完全自动地检测到这种区别,而当暴露的接口中使用的包未被列为对等依赖时,Cabal实际上可能会报告错误(就像它当前阻止导入的方式一样)传递依赖而不明确依赖它。这将允许帮助程序功能包继续保持实现细节,同时仍保持强大的接口安全性。这可能需要做很多工作才能正确管理类型类实例的全局特性,这可能会比天真的方法更加复杂 - 但它会增加一层目前尚不存在的灵活性。
从JavaScript的角度来看,npm已经证明它可以成为一个有能力的包管理器,尽管不断增长的,不断变化的JS生态系统给它带来了巨大的负担。作为一个软件包作者自己,我会恳请其他用户仔细考虑对等依赖关系功能,并努力使用它来编码他们的接口契约 - 这是npm模型中一个常被误解的宝石,我希望这篇博文有助于解决这个问题。
-
Spring中IoC两种接口和两种依赖注入方式的比较
2017-01-21 13:33:55Spring也同时支持两种依赖注入方式:设值注入和构造注入。 这两种依赖注入的方式,并没有绝对的好坏,只是适应的场景有所不同。 相比之下,设值注入有如下优点: 设值注入需要该Bean包含这些属性的setter...spring是一个开源框架,是为了解决企业应用程序开发的复杂性而创建的,为J2EE应用程序开发提供集成的框架。简单来说,spring是一个轻量级的控制反转IOC和面向切面AOP的容器框架。spring框架会对定义在配置文件中的bean实例自动管理,这个bean也就是Java实例,Java组件,spring既可以管理标准的javabean,又可以管理普通的Java组件。
spring框架包含许多特征,并被很好的组织在如下六大模块中:
spring框架中,最基础,最核心的功能是控制反转IoC,面向切面和声明式事物等功能都依赖于控制反转的实现,为了实现控制反转的功能,
spring提供了两个访问接口。
Spring中实现IoC的两种接口介绍
org.springframework.beans.factory.BeanFactory:Bean工厂,借助配置文件能够实现对JavaBean的配置和管理,用于向使用者提供Bean实例。
org.springframework.context.ApplicationContext:ApplicationContext构建在BeanFactory的基础上,提供了更多的实用功能。
配置文件代码如下:
<?xmlversion="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="http://www.springframework.org/schema/p" xsi:schemaLocation="http://www.springframework.org/schema/beanshttp://www.springframework.org/schema/beans/spring-beans-3.1.xsd"> <beanid="book" class="book.Book"> <propertyname="name" value="ssh开发"></property> <propertyname="author" value="李白"></property> <propertyname="publishHouse" value="某出版社"></property> <propertyname="price" value="70"></property> </bean> </beans>
分别使用以上两种方法装载配置文件,进行对比:
一,使用BeanFactory
publicclass BeanFactoryExample { publicstatic void main(String[] args) { //TODO Auto-generated method stub ClassPathResourceresource=new ClassPathResource("applicationContext.xml"); DefaultListableBeanFactoryfactory=new DefaultListableBeanFactory(); XmlBeanDefinitionReaderreader=new XmlBeanDefinitionReader(factory); reader.loadBeanDefinitions(resource);//加载配置文件 Bookbook=(Book)factory.getBean("book"); /*DefaultListableBeanFactory中的getBean()方法从容器中获得Bean对象*/ System.out.println(book.getName()); System.out.println(book.getAuthor()); System.out.println(book.getPublishHouse()); System.out.println(book.getPrice()); } }
二,使用ApplicationContext
publicclass ApplicationContextExample { publicstatic void main(String[] args) { //TODO Auto-generated method stub ClassPathXmlApplicationContextcontext= newClassPathXmlApplicationContext("applicationContext.xml"); Bookbook=(Book)context.getBean("book"); System.out.println(book.getName()); System.out.println(book.getAuthor()); System.out.println(book.getPublishHouse()); System.out.println(book.getPrice()); context.close(); /*ClassPathXmlApplicationContext类实现了java.io.Closeable接口,所以用完要调用close()方法关闭*/ } }
两种测试运行结果是一致的:
ssh开发
李白
某出版社
70
那么,在开发中到底选择哪个接口更合适呢?
Spring对象属性的注入方式有两种:设值注入和构造注入。
1.设值注入:
<bean id="people" class="com.abc.People"> <property name="name" value="熊九天" /> <!-- 设值注入 --> <property name="school" ref="school" /> <!-- 设值注入 --> <property name="age" value="20" type="int" /> </bean> <bean id="school" class="com.abc.School" />
2.构造注入:
<bean id="people" class="com.abc.People"> <!-- 构造注入,index=0表示构造器的第一个参数 --> <constructor-arg index="0" value="熊九天"/> <constructor-arg index="1" ref="school" /> <!-- 构造注入 --> <constructor-arg index="2" value="20" type="int" /> </bean> <bean id="school" class="com.abc.School" />
两者的区别和使用场景:
在过去的开发过程中,这两种注入方式都是非常常用的。Spring也同时支持两种依赖注入方式:设值注入和构造注入。 这两种依赖注入的方式,并没有绝对的好坏,只是适应的场景有所不同。 相比之下,设值注入有如下优点:
- 设值注入需要该Bean包含这些属性的setter方法
- 与传统的JavaBean的写法更相似,程序开发人员更容易理解、接收。通过setter方法设定依赖关系显得更加只管。
- 对于复杂的依赖关系,如果采用构造注入,会导致构造器国语臃肿,难以阅读。Spring在创建Bean实例时,需要同时实例化器依赖的全部实例,因而导致性能下降。而使用设值注入,则能避免这些问题
- 尤其是在某些属性可选的情况况下,多参数的构造器显得更加笨重
构造注入也不是绝对不如设值注入,在某些特定的场景下,构造注入比设值注入更加优秀。构造注入有以下优势:
- 构造注入需要该Bean包含带有这些属性的构造器
- 构造注入可以在构造器中决定依赖关系的注入顺序,优先依赖的优先注入。例如,组件中其他依赖关系的注入,常常要依赖于DataSrouce的注入。采用构造注入,可以在代码中清晰的决定注入顺序。
- 对于依赖关系无需变化的Bean,构造注入更有用处。因为没有Setter方法,所有的依赖关系全部在构造器内设定。因此,无需担心后续的代码对依赖关系产生破坏。
- 依赖关系只能在构造器中设定,则只有组件的创建者才能改变组件的依赖关系。对组件的调用者而言,组件内部的依赖关系完全透明,更符合高内聚的原则。
建议:采用以设值注入为主,构造注入为辅的注入策略。对于依赖关系无需变化的注入,尽量采用构造注入;而其他的依赖关系的注入,则考虑采用设值注入。
-
[总结]关系数据库设计基础(函数依赖、无损连接性、保持函数依赖、范式、……)
2020-12-19 11:42:41联系(Relationship)1:1联系:如果实体集E1中的每个实体最多只能和实体集E2中一个...函数依赖(FunctionDependency)定义设关系模式R(U),属性集合U={A1,A2,…,An},X,Y为属性集合U的子集,如果对于关系模式R(U)...联系(Relationship)1:1联系:如果实体集E1中的每个实体最多只能和实体集E2中一个实体有联系,反之亦然,那么实体集E1对E2的联系成为一对一联系,记为1:1;
1:N联系:一对多,记为1:N;
M:N联系:多对多联系,记为M:N。
函数依赖(Function
Dependency)
定义设关系模式R(U),属性集合U={A1,A2,…,An},X,Y为属性集合U的子集,如果对于关系模式R(U)的任一可能的关系r,r中的任意两个元组u、v,若有u[X]=v[X],就有u[Y]=v[Y],则称X函数决定Y,或称Y函数依赖于X。用符号X→Y表示。其中X为决定因素,Y为被决定因素。若对于R(U)的任意一个可能的关系r,r中不可能存在两个元组在X上的属性值性等,而在Y上的属性值不等。 (1) 函数依赖是语义范畴的概念,只能根据语义来确定一个函数依赖关系。
(2)
函数依赖X→Y的定义要求关系模式R的任何可能的关系r中的元组都满足函数依赖条件。术语(1)若X→Y,则X称作决定因素(Determinant)
(2)若X→Y,Y→X,称作XY。
(3)若Y不函数依赖于X,称作X -/-> Y。
(4)X→Y,若Y不包含X,则称X→Y为非平凡的函数依赖。正常讨论的都是非平凡的函数依赖。
(5)X→Y,若Y包含X,则称X→Y为平凡的函数依赖。
(6)完全函数依赖(full
functional dependency):在R(U)中,设X、Y是关系模式R(U)中不同的属性子集,若存在
X→Y,且不存在 X的任何真子集X',使得
X'→Y,则称Y完全函数依赖 ( full functional dependency ) 于X。记作
X-F->Y。
(7)部分函数依赖:在关系模式R(U)中,X、Y是关系模式R(U)中不同的属性子集,若X→Y成立,如果X中存在任何真子集X',而且有X'→Y也成立,则称Y对X是部分函数依赖,记作:X-P->Y。
(8)设R是关系模式,U是其属性集,K包含于U。若K完全函数确定U,则称K是R的候选键(又叫候选关键字,候选码)。包含在任意候选键内的属性称为键属性(又叫主属性),不是键属性的属性称为非键属性(又叫非主属性)。显然,候选键可以唯一标识关系的元组。候选键可能不唯一,通常指定一个候选键作为识别元组的主键。
候选键的严格定义:
关系模式R(U)的属性集合K ∈U的候选键,如果
(1)R(U)的任何一个关系实例的任意两个元素在属性集合K上的值部不相同————唯一性
(2)K的任何真子集都不满足条件 ————最小性
通俗点,候选键在每一行数据里的值都不相同,就像自动增长的id一样,可以说成是候选的主键。
码(键)是数据系统中的基本概念。所谓码就是能唯一标识实体的属性,它是整个实体集的性质,而不是单个实体的性质。
它包括超码,候选码,主码。
超键(super
key):在关系中能唯一标识元组的属性集称为关系模式的超键(又叫超码),超码是一个或多个属性的集合,这些属性可以让我们在一个实体集中唯一地标识一个实体。超码的任意超集也是超码,也就是说如果K是超码,那么所有包含K的集合也是超码。
候选键(candidate
key):不含有多余属性的超键称为候选键(又叫候选码)。候选码是从超码中选出的,自然地候选码也是一个或多个属性的集合。因为超码的范围太广,很多是我们并不感兴趣即无用处的。所以候选码是最小超码,它们的任意真子集都不能成为超码。
主键(primary key):用户选作元组标识的一个候选键程序主键(又叫主码)
一题搞懂什么是候选键
学号
姓名
性别
年龄
系别
专业
20020612
李辉
男
20
计算机
软件开发
20020613
张明
男
19
计算机
软件开发
20020614
王小玉
女
18
物理
力学
20020615
李淑华
女
17
生物
动物学
20020616
赵静
男
21
化学
食品化学
20020617
赵静
女
20
生物
植物学
【题目】数据库中有一个学生信息表如上所示,在该表中不能作为候选键的属性集合为( )
(选择一项)
a){学号} b){学号、姓名} c){年龄、系别} d){姓名、性别} e){姓名、专业}
【解析】透过概念,我们可以了解到,超键包含着候选键,候选键中包含着主键。主键一定是惟一的。为什么呢?因为他的爷爷超键就是惟一的。
我们分析一下上面的题目,a,b,c,d,e,5个答案都可以作为超键,他们组合在一起的集合可以用来惟一的标识一条数据记录(实体)。
请注意我们的要求:候选键。候选键要求是不能包含多余属性的超键,我们看一下答案b。在答案b中,如果我们不使用姓名也可以惟一的 标识一条数据实体,可以说姓名字段在这里是多余的。那么很明显,b选项包含了多余字段属性。那么这题答案应该选择b。
那么其他的4个选项都可以作为候选键,假设很幸运,a){学号}被选择作为用户正在使用的候选键来惟一标识元组了,那么他很幸运的获得了主键的称号
【答案】b
(9)若关系R的属性子集X是另一关系S的候选键,则称X是R关于S的外部键。主键和外部键描述了关系之间的联系。
(10)传递函数依赖:在关系模式R(U)
中,如果Y→X,X→A,且X
Y(X不决定Y), A
X(A不属于X),那么称Y→A是传递依赖。
函数依赖的推理规则
1.
逻辑蕴含 给定一个关系模式,只考虑给定的函数依赖是不够的,必须找出在该关系模式上成立的其他函数依赖。
逻辑蕴含:设F是关系模式R(U)的函数依赖集合,由F出发,可以证明其他某些函数依赖也成立,我们称这些函数依赖被F逻辑蕴含。"F蕴含X→Y"意味着关系实例只要满足F就满足X→Y。 例如,设F={ A→B,B→C },则函数依赖A→C被F逻辑蕴含,记作:F |=
A→C。即函数依赖集 F 逻辑蕴含函数依赖A→C。
2.
F的闭包F+
对于一个关系模式,如何由已知的函数依赖集合F,找出F逻辑蕴涵的所有函数依赖集合呢?这就是我们下面要讨论的问题。
F的闭包F+:设F为一个函数依赖集,F的闭包是指F逻辑蕴涵的所有函数依赖集合。
F的闭包记作F+。
例如,给定关系模式R(A,B,C,G,H,I),函数依赖集合F={A→B,A→C,CG→H,CG→I,B→H}。可以证明函数依赖A→H被F逻辑蕴涵。
设有元组s和t,满足s[A]=t[A],根据函数依赖的定义,由已知的A→B,可以推出s[B]=t[B]。又根据函数依赖B→H,可以有s[H]=t[H]。因此,已经证明对任意的两个元组s和t,只要有s[A]=t[A],就有s[H]=t[H]。所以,函数依赖A→H被F逻辑蕴涵。
计算F的闭包F+,可以由函数依赖的定义直接计算,如上面的示例。但是,当F很大时,计算的过程会很长。为了从已知的函数依赖推导出其它函数依赖,Armstrong
提出了一套推理规则,称为Armstrong 公理
,通过反复使用这些规则,可以找出给定F的闭包F+。其推理规则可归结为如下3条:自反律(reflexivity)、增广律(augmentation)和
传递律(transitivity)。
3.Armstrong 公理
设U为属性总体集合,F为U上的一组函数依赖,对于关系模式R(U,F),X、Y、Z为属性U的子集,有下列推理规则:
A1:自反律(reflexivity) 若Y X U,则X→Y为F所蕴函。
A2:增广律(augmentation) 若X→Y为F所蕴函,且Z是U的子集,则XZ→YZ为F所蕴函。式中XZ和YZ是X∪Z 和 Y∪Z的简写。
A3:传递律(transitivity) 若X→Y、Y→Z为F所蕴函,则X→Z为F所蕴函。
由自反律所得到的函数依赖都是平凡的函数依赖,自反律的使用并不依赖于F,而只依赖于属性集U。
Armstrong公理是有效的和完备的。可以利用该公理系统推导F的闭包F+。由于利用Armstrong公理直接计算F+很麻烦。根据A1,
A2, A3这三条推理规则还可以得到其他规则,用于简化计算F+的工作。如下面扩展的三条推理规则:
*合并规则: 由X→Y, X→Z, 有X→YZ
*伪传递规则: 由X→Y, WY→Z, 有XW→Z
*分解规则: 由X→YZ, 则有X→Z,X→Y
Armstrong公理可以有多种表示形式,例如,增广律A2可以用合并规则代替。例如,用自反律A1,传递律A3和合并规则可推导出增广律A2。
证明:XZ →X (A1:自反律) X →Y (给定条件) XZ →Y (A3:传递律) XZ →Z
(A1:自反律) XZ →YZ (合并规则)4.属性集的闭包
原则上讲,对于一个关系模式R(U,F),根据已知的函数依赖F,反复使用前面的规则,可以计算函数依赖集合F的闭包F+。但是,利用推理规则求出其全部的函数依赖F+是非常困难的,而且也没有必要。因此,可以计算闭包的子集,即选择一个属性子集,判断该属性子集能函数决定哪些属性,这就是利用属性集闭包的概念。
(1)属性集闭包的定义
设F为属性集U上的函数依赖集,X∈U,即X为U的一个子集。在函数依赖集F下被X函数决定的所有属性为F+下属性集X的闭包,记作X+。即X+={
A| X→A } 。
(2)计算属性集闭包X+的算法如下:
输入:X,F
输出: X+ 迭代算法的步骤:
① 选取X+的初始值为X ,即X+={X};
② 计算X+, X+={X,Z} ,其中Z要满足如下条件:
Y是X+的真子集,且F中存在一函数依赖Y→Z。实际上就是以X+中的属性子集作为函数依赖的决定因素,在F中搜索函数依赖集,找到函数依赖的被决定属性Z放到X+中。
③
判断:如果X+没有变化?或X+等于U?则X+就是所求的结果,算法终止。否则转②。
因为U是有穷的,所以上述迭代过程经过有限步骤之后就会终止。
例如,已知关系模式R(U,F),U={A,B,C,D,E,G},F={AB→C,D→EG,C→A,BE→C,BC→D,AC→B,CE→AG},求(BD)+
解:
① (BD)+ = {BD};
②
计算(BD)+ ,在F中扫描函数依赖,其左边为B,D或BD的函数依赖,得到一个D→EG。所以,(BD)+=
{BDEG}。
③
计算(BD)+,在F中查找左部为BDEG的所有函数依赖,有两个:D→EG和BE→C。所以(BD)+={(BD)∪EGC}={BCDEG}。
④
计算(BD)+,在F中查找左部为BCDEG子集的函数依赖,除去已经找过的以外,还有三个新的函数依赖:C→A,BC→D,CE→AG。得到(BD)+={(BD)∪ADG}={ABCDEG}。
⑤ 判断(BD)+=U,算法结束。得到(BD)+={ABCDEG}。
说明:上面说明(B,D)是该关系模式的一个候选码。
5.
Armstrong公理系统的有效性和完备性
①Armstrong公理系统的有效性指的是:由F出发根据Armstrong公理系统推导出来的每一个函数依赖一定是F所逻辑蕴含的函数依赖。
②Armstrong公理系统的完备性指的是:对于F所逻辑蕴含的每一函数依赖,必定可以由F出发根据Armstrong公理系统推导出来。
6. 极小函数依赖集(最小函数依赖集)
定义:如果函数依赖集F满足下列条件,则称F为最小函数依赖集或最小覆盖。
① F中的任何一个函数依赖的右部仅含有一个属性;
② F中不存在这样一个函数依赖X→A,使得F与F-{X→A}等价;
③ F中不存在这样一个函数依赖X→A,X有真子集Z使得F-{X→A}∪{Z→A}与F等价。
求最小函数依赖集分三步:
1.将F中的所有依赖右边化为单一元素
此题fd={abd->e,ab->g,b->f,c->j,cj->i,g->h};已经满足
2.去掉F中的所有依赖左边的冗余属性. 作法是属性中去掉其中的一个,看看是否依然可以推导
此题:abd->e,去掉a,则(bd)+不含e,故不能去掉,同理b,d都不是冗余属性 ab->g,也没有
cj->i,因为c+={c,j,i}其中包含i所以j是冗余的.cj->i将成为c->i F={abd->e,ab->g,b->f,c->j,c->i,g->h};
3.去掉F中所有冗余依赖关系.
做法为从F中去掉某关系,如去掉(X->Y),然后在F中求X+,如果Y在X+中,则表明x->是多余的.需要去掉.
此题如果F去掉abd->e,F将等于{ab->g,b->f,c->j,c->i,g->h},而(abd)+={a,d,b,f,g,h},其中不包含e.所有不是多余的.
同理(ab)+={a,b,f}也不包含g,故不是多余的.
b+={b}不多余,c+={c,i}不多余
c->i,g->h多不能去掉.
所以所求最小函数依赖集为
F={abd->e,ab->g,b->f,c->j,c->i,g->h};
多值依赖
1、定义
设R(U)是属性集U上的一个关系模式。X,Y,Z是U的子集,并且Z=U-X-Y。关系模式R(U)中多值依赖X→→Y成立,当且仅当对R(U)的任一关系r,给定的一对(x,z)值有一组Y的值,这组值仅仅决定于x值而与z值无关。
若X→→Y,而Z=
,则称X→→Y为平凡的多值依赖。否则称X→→Y为非平凡的多值依赖。
多值依赖也可以形式化地定义如下:
在关系模式R(U)的任一关系r中,如果对于任意两个元组t,s,有t[X]=s[X],就必存在元组w,v∈r(w和v可以与s和t相同),使得w[X]=v[X]=t[X],而w[Y]=t[Y],w[Z]=s[Z],v[Y]=t[Z],即交换s,t元组的Y值所得的两个新元组必在r中,则称Y多值依赖于X,记为X→→Y。其中,X和Y是U的子集,Z=U-X-Y。
多值依赖属4nf的定义范围,比函数依赖要复杂得多,很多书上都没有讲清楚。
2、说得简单点就是
在关系模式中,函数依赖不能表示属性值之间的一对多联系,这些属性之间有些虽然没有直接关系,但存在间接的关系,把没有直接联系、但有间接的联系称为多值依赖的数据依赖。例如,教师和学生之间没有直接联系,但教师和学生可通过系名,或任课把教师和学生联系起来。
3、举例如下
【例1】有这样一个关系
,假设一个一个产品只能放到一个仓库中,但是一个仓库可以由若干管理员,那么对应于一个
【例2】(C,B)上的一个值(物理,光学原理)对应一组T值(李平,王强,刘明),这组值仅仅决定于课程C上的值,也就是说对于(C,B)上的另一个值(物理,普通物理学),它对应的一组T值仍是(李平,王强,刘明),尽管这时参考书B的值已经改变了。因此T多值依赖于C,即C→→T。
4、多值依赖具有下列性质
●多值依赖具有对称性。即若X→→Y,则X→→Z,其中Z=U-X-Y。
●多值依赖具有传递性。即若X→→Y,Y→→Z,则X→→Z-Y。
●函数依赖可以看作是多值依赖的特殊情况。
●若X→→Y,X→→Z,则X→→YZ。
●若X→→Y,X→→Z,则X→→Y∩Z。
●若X→→Y,X→→Z,则X→→Y-Z,X→→Z-Y。
●多值依赖的有效性与属性集的范围有关。
●若多值依赖X→→Y在R(U)上成立,对于Y'
Y,并不一定有X→→Y’成立。但是如果函数依赖X→Y在R上成立,则对于任何Y'
Y均有X→Y’成立。
范式
• 如果某个数据库模式都是第一范式的,则称该数据库模式是属于第一范式的数据库模式。【无重复的列】
缺点:数据冗余,删除异常,插入异常,修改复杂• 如果关系模式R为第一范式,并且R中每一个非主属性完全函数依赖于R的某个候选键,则称为第二范式模式。【消去非主属性对键的部分函数依赖】 缺点:删除异常,插入异常,修改复杂• 如果关系模式R是第二范式,且每个非主属性都不传递依赖于R的候选键,则称R为第三范式模式。【消去非主属性对键的部分和传递函数依赖】• 若关系模式R是第一范式,且每个属性都不传递依赖于R的候选键。这种关系模式就是BCNF模式。【消去主属性对键的部分和传递函数依赖】
若R上的多值依赖集合D中成立非平凡多值依赖X→→Y时,X必是R的超键,则R∈4NF。
由BCNF的定义可以得到以下结论,一个满足BCNF的关系模式有: 所有非主属性对每一个码都是完全函数依赖。
所有的主属性对每一个不包含它的码,也是完全函数依赖。
没有任何属性完全函数依赖子非码的任何一组属性。
由于R∈BCNF,按定义排除了任何属性对码的传递依赖与部分依赖;所以R∈3NF。
• 若关系模式R是第一范式,且对于R的每个非平凡多值依赖X→→Y(Y
X),X都含有码,则称R∈4NF。【消除非平凡且非函数依赖的多值依赖】
4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。因为根据定义,对于每一个非平凡的多值依赖X→→Y,X都含有候选码,于是就有X→Y,所以4NF所允许的非平凡的多值依赖实际上是函数依赖。
•设R,R1,R2,...,Rn是关系模式,U,U1,U2,...,Un分别是R,R1,R2,...,Rn的属性集合,而且U=U1∪U2∪...∪Un。如果R的任意关系实例r满足:
r=πR1(r) ⋈ πR2(r) ⋈
... ⋈ πRn(r),则称R满足联结依赖,记作⋈(R1,R2,...,Rn)
R中除了超建构成的联结依赖外,没有其他联结依赖存在,称R为5NF。
判断无损连接和函数依赖
大部分是对一个关系模式分解成两个模式的考察,分解为三个以上模式时无损分解和保持依赖的判断比较复杂,考的可能性不大,因此我们只对“一个关系模式分解成两个模式”这种类型的题的相关判断做一个总结。
以下的论述都基于这样一个前提:
R是具有函数依赖集F的关系模式,(R1 ,R2)是R的一个分解。
首先我们给出一个看似无关却非常重要的概念:属性集的闭包。
令α为一属性集。我们称在函数依赖集F下由α函数确定的所有属性的集合为F下α的闭包,记为α+ 。
下面给出一个计算α+的算法,该算法的输入是函数依赖集F和属性集α,输出存储在变量result中。
算法一:
result:=α;
while(result发生变化)do
for each
函数依赖β→γ in F do
begin
if β∈result then result:=result∪γ;
end
属性集闭包的计算有以下两个常用用途:
·判断α是否为超码,通过计算α+(α在F下的闭包),看α+ 是否包含了R中的所有属性。若是,则α为R的超码。
·通过检验是否β∈α+,来验证函数依赖是否成立。也就是说,用属性闭包计算α+,看它是否包含β。
(请原谅我用∈符号来表示两个集合之间的包含关系,那个表示包含的符号我找不到,大家知道是什么意思就行了。)
看一个例子吧,2005年11月系分上午37题:
●
给定关系R(A1,A2,A3,A4)上的函数依赖集F={A1→A2,A3→A2,A2→A3,A2→A4},R的候选关键字为________。
(37)A. A1 B. A1A3 C. A1A3A4 D. A1A2A3
首先我们按照上面的算法计算A1+ 。
result=A1,
由于A1→A2,A1∈result,所以result=result∪A2=A1A2
由于A2→A3,A2∈result,所以result=result∪A3=A1A2A3
由于A2→A4,A2∈result,所以result=result∪A3=A1A2A3A4
由于A3→A2,A3∈result,所以result=result∪A2=A1A2A3A4
通过计算我们看到,A1+ =result={A1A2A3A4},所以A1是R的超码,理所当然是R的候选关键字。此题选A 。
好了,有了前面的铺垫,我们进入正题。
无损分解的判断。
如果R1∩R2是R1或R2的超码,则R上的分解(R1,R2)是无损分解。这是一个充分条件,当所有的约束都是函数依赖时它才是必要条件(例如多值依赖就是一种非函数依赖的约束),不过这已经足够了。
保持依赖的判断。
如果F上的每一个函数依赖都在其分解后的某一个关系上成立,则这个分解是保持依赖的(这是一个充分条件)。
如果上述判断失败,并不能断言分解不是保持依赖的,还要使用下面的通用方法来做进一步判断。
该方法的表述如下:
算法二:
对F上的每一个α→β使用下面的过程:
result:=α;
while(result发生变化)do
for each
分解后的Ri
t=(result∩Ri)+ ∩Ri
result=result∪t
这里的属性闭包是在函数依赖集F下计算出来的。如果result中包含了β的所有属性,则函数依赖α→β。分解是保持依赖的当且仅当上述过程中F的所有依赖都被保持。
下面给出一个例题,2006年5月系分上午43题:
●设关系模式R,其中U={A, B, C, D,
E},F={A→BC,C→D,BC→E,E→A},则分解ρ={R1(ABCE),R2(CD)}满足 (43) 。
(43) A.具有无损连接性、保持函数依赖
B.不具有无损连接性、保持函数依赖
C.具有无损连接性、不保持函数依赖
D.不具有无损连接性、不保持函数依赖
先做无损链接的判断。R1∩R2={C},计算C+。
Result=C
由于C→D,C∈result,所以result=result∪D=CD
可见C是R2的超码,该分解是一个无损分解。
再做保持依赖的判断。
A→BC,BC→E,
E→A都在R1上成立(也就是说每一个函数依赖左右两边的属性都在R1中),C→D在R2上成立,因此给分解是保持依赖的。
选A。
再看一个复杂点的例题。2007年5月数工40-41题。
●给定关系模式R,U={A, B, C, D,
E},F={B→A,D→A,A→E,AC→B},其候选关键字为 (40) ,则分解ρ={R1(ABCE),R2(CD)}满足 (41) 。
(40) A.ABD
B.ABE
C.ACD
D.CD
(41) A.具有无损连接性、保持函数依赖
B.不具有无损连接性、保持函数依赖
C.具有无损连接性、不保持函数依赖
D.不具有无损连接性、不保持函数依赖
看见了吧,和前面一题多么的相像!
对于第一问,分别计算ABCD四个选项的闭包,
(ABD)+ = { ABDE }
(ABE)+ = { ABE }
(ACD)+ = { ABCDE }
(CD)+ = { ABCDE }
选D。
再看第二问。
先做无损链接的判断。R1∩R2={C},计算C+。
result=C
因此C既不是R1也不是R2的超码,该分解不具有无损分解性。
再做保持依赖的判断。
B→A,A→E,AC→B在R1上成立,D→A在R1和R2上都不成立,因此需做进一步判断。
由于B→A,A→E,AC→B都是被保持的(因为它们的元素都在R1中),因此我们要判断的是D→A是不是也被保持。
对于D→A应用算法二:
result=D
对R1,result∩R1=ф(空集,找不到空集的符号,就用这个表示吧),t=ф,result=D
再对R2,result∩R2=D,D+ =ADE ,t=D+ ∩R2=D,result=D
一个循环后result未发生变化,因此最后result=D,并未包含A,所以D→A未被保持,该分解不是保持依赖的。
选D。
-
常见算法优缺点
2020-12-31 12:39:471.朴素贝叶斯朴素贝叶斯属于生成式模型(关于生成模型和判别式模型,主要还是在于是否是要求联合分布),非常简单,你只是做了一堆计数。...它的主要缺点是它不能学习特征间的相互作用,用mRMR中R来讲,就是特征冗余... -
「收藏」人工智能中常见机器学习算法优缺点有哪些?
2019-06-30 12:25:264. 循环步骤1,2,3来继续训练多个分类器,只是其D值不同而已。 测试过程如下: 输入一个样本到训练好的每个弱分类中,则每个弱分类都对应一个输出标签,然后该标签乘以对应的α,最后求和得到值的符号即为预测... -
深入理解 ASP.NET Core 依赖注入
2019-02-11 14:48:53对于 ASP.NET Core 的依赖注入、控制反转以及 Autofac 等一直没有搞明白,但这篇文章让我从根本上了解了尤其是依赖注入的概念以及在 ASP.NET Core 中的应用,特推荐给需要的你。 一、什么是依赖注入... -
常见分类算法优缺点
2018-10-21 21:36:54本文主要回顾下几个常用算法的适应场景及其优缺点! 机器学习算法太多了,分类、回归、聚类、推荐、图像识别领域等等,要想找到一个合适算法真的不容易,所以在实际应用中,我们一般都是采用启发式学习方式来实验。... -
【大数据哔哔集20210110】后起之秀ClickHouse的优缺点和核心特性
2021-01-21 00:00:00点击上方蓝色字体,选择“设为星标”回复”资源“获取更多惊喜ClickHouse is a column-oriented database management system (DBMS... -
深入理解XGBoost,优缺点分析,原理推导及工程实现
2019-12-26 20:04:00列块并行学习的设计可以减少节点分裂时的计算量,在顺序访问特征值时,访问的是一块连续的内存空间,但通过特征值持有的索引(样本索引)访问样本获取一阶、二阶导数时,这个访问操作访问的内存空间并不连续,这样... -
KNNImputer:一种可靠的缺失值插补方法
2020-07-28 12:01:32学会用KNNImputer来填补数据中的缺失值 了解缺失值及其类型 介绍 scikit learn公司的KNNImputer是一种广泛使用的缺失值插补方法。它被广泛认为是传统插补技术的替代品。 在当今世界,数据是从许多来源收集的,... -
数据库入门(一)范式理解:1NF,2NF,3NF,BCNF,4NF详析
2020-12-14 15:24:124NF详析引言范式种类第一范式(1NF)符合1NF的关系中的每个属性都不可再...缺点BCNF范式(3NF的改进形式)BCNF条件为什么引入BCNF解决方法第四范式(4NF)相关概念介绍多值依赖Teaching模式中存在的问题平凡函数依赖和... -
5种分布式事务解决方案优缺点对比
2019-07-27 20:24:33一致性:在分布式系统中的所有数据备份,在同一时刻是否同样的值。 可用性:在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。 分区容忍性:以实际效果而言,分区相当于对通信的时限要求。... -
spring依赖注入方式及其优缺点
2014-08-29 14:59:26Type2 设值注入: 在各种类型的依赖注入模式中,设值注入模式在实际开发中得到了最广泛的应用(其中很大一部分得力于Spring框架的 影响)。使用IoC的Setter注射,一些外部元数据被用于解决依赖性问题。并且在... -
Spring-Cache的基本使用和缺点
2022-03-11 16:38:37Spring官方支持了一些配置,帮助我们操作缓存。(官方学习文档)可以帮我们简化很多操作,只需要使用几个注解,就可以帮助我们对更改的操作写入到缓存中。本文推荐使用失效模式 -
Spring注入方式及优缺点
2020-09-12 15:46:45Spring依赖注入的方式有:构造器注入,setter方法注入、属性注入、工厂方法注入,官方3.x版本推荐使用setter方法注入,到4.x之后官方推荐使用构造器注入。 1、构造器注入 通过构造器注入Shop这个Bean到Person中,... -
[机器学习] 数据缺失的处理方法及其优缺点分析
2022-04-02 10:43:53参考:数据缺失的处理方法及其优缺点分析 - 知乎 一、缺失值的原因 缺失值是指粗糙数据中由于缺少信息而造成的数据的聚类、分组、删失或截断。它指的是现有数据集中某个或某些属性的值是不完全的。缺失值的产生的... -
模型优缺点总结
2020-12-26 16:06:49自动地运用CPU的多线程进行并行计算 对于缺失值的特征,通过枚举所有缺失值在当前节点是进入左子树还是右子树来决定缺失值的处理方式 缺点: 空间消耗大。这样的算法需要保存数据的特征值,还保存了特征排序的结果... -
RNN,LSTM,GRU计算方式及优缺点
2020-06-21 15:44:43对比这三者的优缺点 1.RNN,LSTM,GRU结构及计算方式 1.1 Navie RNN 结构图: 计算公式: ht=σ(Whht−1+Wxxt)yt=σ(Wyht) h^t=\sigma(W^hh^{t-1}+W^xx^t)\\y^t=\sigma(W^yh^t) ht=σ(Whht−1+Wxxt)yt=σ(Wyht) 依赖... -
函数依赖和关系模式分解
2020-06-23 10:11:40文章目录一,第一范式关系数据库设计中易犯的错误数据...---- 多值属性:电话号码 ---- 复合数据类型:面向对象的 如果关系模式R中的所有属性的域是原子的,则R称为属于第一范式(1NF) 非原子值存储复杂并易导致数 -
详细讲解MYSQL视图的作用及优缺点
2021-04-25 00:25:35五、视图的缺点 1.性能:从数据库视图查询数据可能会很慢,特别是如果视图是基于其他视图创建的。 2.表依赖关系:将根据数据库的基础表创建一个视图。每当更改与其相关联的表的结构时,都必须更改视图。 六、视图的... -
控制反转IOC、依赖注入DI的详细说明与举例
2020-10-03 22:17:20文章目录引入IOC介绍IOC的实现通过构造函数注入依赖通过 setter 设值方法注入依赖依赖注入容器 阅读时忽略语言差异,参考博文在最后给出 引入 由于 HTTP 协议是一种无状态的协议,所以我们就需要使用「Session(会话... -
01-Partial Dependence Plot(PDP)部分依赖图
2021-08-16 19:39:57PDP缺点 参考网址: [1] Interpretable Machine Learning 1. PDP理论 部分依赖图显示了一个或两个特征对ML模型预测结果的边际影响。部分依赖图可以显示目标和特征之间的关系是线性的、单调的还是更复杂的。例如,当... -
全局变量的优缺点
2020-08-22 18:56:16全局变量的优缺点 1. 写在前面 在上一文中,我谈到了在完成项目中将需要的变量分为了“全局变量”和“局部变量”,但是在后来的学习中发现,虽然全局变量有一些优点,但同时也伴随着许多的缺点,于是在此做出一些小... -
Spring依赖注入的三种方式(好的 坏的和丑的)
2019-01-13 10:25:20关于spring bean三种注入方式的优缺点对比,翻译自Spring DI Patterns: The Good, The Bad, and The Ugly,水平有限,如有错误请指正。 Spring开发者会很熟悉spring强大的依赖注入API,这些API可以让你用@Bean的... -
深度学习---RNN循环神经网络&LSTM解决长依赖问题
2020-07-19 19:39:42神经网络只能单独的处理一个个的输入,前一个输入和后一个输入是完全没有关系的。但是,在我们处理某些任务时,要...循环神经网络首先把所有的输入值进行词组的分解 隐藏层的作用是对序列数据提取特征 h2 的计算和 h1 -
依赖注入和控制反转的理解
2020-08-31 15:54:39Spring 能有效地组织J2EE应用各层的对象。不管是控制层的Action对象,还是业务层的Service对象,还是持久层的DAO对象,都可在Spring的 管理下有机地协调、运行。...依赖注入让bean与bean之间以配置文件组织 -
系统学习机器学习之总结(一)--常见分类算法优缺点
2018-09-26 14:37:47其实,这里更多的是从基础版本对比,真正使用的时候,看数据,看改进后的算法。 1. 五大流派 ①符号主义:使用符号、规则和逻辑来表征知识和进行逻辑推理,最喜欢的算法是:规则和决策树 ②贝叶斯派:获取发生的... -
机器学习常见算法优缺点
2016-12-28 17:50:491. K近邻 算法采用测量不同特征值之间的距离的方法进行分类。 1.1 优点 简单好用,容易理解,精度高,理论成熟,既...样本不平衡问题(即有些类别的样本数量很多,而其它样本的数量很少); 一般数值很大的时候不用 -
机器学习各类算法的优缺点
2018-07-30 22:06:191.逻辑回归 二项logistic回归模型是一种分类模型,由条件概率分布P(Y|X)表示,形式为参数化的logistic分布。这里随机变量X取值为实数,随机变量Y取值为1或0。可以通过有监督的方法来...缺点: 1. 容易欠拟合,分...