技术改变世界 阅读塑造人生! - shaogx.com

This string was altered by TechBlog\Plugins\Example.; This is an example to show the potential of an offcanvas layout pattern in Bootstrap. Try some responsive-range viewport sizes to see it in action.

数据库、多维数据集和挖掘模型角色

角色(也称为安全性角色)定义了一组 Microsoft® Windows NT® 4.0 或 Windows® 2000 用户帐户和组,它们对于 Microsoft SQL Server™ 2000 Analysis Services 数据具有相同的访问权限。角色是用来实现最终用户安全性的,实现方法是通过从客户应用程序连接的用户来控制对分析服务器上数据的访问。Analysis Services 包括三类角色:数据库角色、多维数据集角色和挖掘模型角色。... 全文

数据库 多维数据集 挖掘模型

为目标DBMS转换全局逻辑数据模型

在数据库设计方法学的第二个阶段,也就是物理数据库设计阶段,必须确定如何将逻辑数据结构转换为目标DBMS可以实现的物理数据库设计,因为物理数据库设计的许多方面都高度依赖于目标DBMS,你可能会发现不只一种方法可以实现数据库中指定的部分,因此为了正确的完成这项工作,需要具有对目标DBMS功能的全面认识,并且需要理解特定实现细节的每个可供选择的方案的优点和缺点。对某些系统来说,考虑到数据库的使用目的,可能还需要选择合适的存储策略。       逻辑与物理数据库设计有明显的区别,逻辑数据库设计极大的独立于实现细节,逻辑数据库设计关心的是什么,而物理数据库设计关心的是怎么,特别是作为物理数据库设计者必须知道支持DBMS的计算机系统怎样运行,并且必须要有对目标DBMS的功能的整体认识,因为当前系统所提供的功能变化范围很大,因此物理设计必须依赖于具体的DBMS的功能。物理数据库设计的目标是在辅存上产生数据库的实现的过程,它描述了基本表,文件组织方式和用于实现数据有效访问的索引以及任何相关的完整性和安全限制。为目标DBMS转换全局逻辑数据模型的目标是从数据模型产生基本的工作关系数据库。物理数据库设计第一步包括从逻辑数据模型产生的表转换为在目标关系DBMS中可以实现的形式,这一步的第一部分要比较在逻辑数据库设计阶段收集的信息和在数据字典中存档的信息,这步的第一部分要比较在逻辑数据库阶段收集的信息和在数据字典中存档的信息。第二部分要使用这些信息进行基本表的设计,这个过程需要具有非常了解目标DBMS所提供的有关功能的知识。本步骤中包括三个任务,分别是1.         设计基本表。目标是确定如何在目标DBMS中描述在逻辑数据模型表示的基本表。要开始物理设计过程,首先要比较和吸收在逻辑数据库设计阶段创建的表的信息。这些必要的信息可以从数据字典中获得,并且使用数据库设计语言来定义表,对于每个在逻辑数据模型中标示的表,应该有如下的定义,表名,括在括号内的简单列名表,主键以及在适当的地方的备用键,任何表示出的外键的参照完整性约束,任何标识出的外键的参照完整性约束。对于每个列有如下的定义,它的域,包括数据类型,长度和域上的约束。每个列设置可选的默认值,该列是否可以为空,该列是否是派生列,如果是怎样计算。创建的基本表最好使用SQL语句创建。基本表的设计应该完全记录在文档中,这样可以选择设计目标,特别是当有很多选择时,记录下选择其中的一种方法的原因。2.         设计派生数据的表示,目标是设计派生数据在数据库中的表示。如果一个列的值可以从其它列得到,则此列就成为派生列或者计算列,例如,一个公司的全部人数可以通过统计查询来做,派生列经常不出现在ER模型中,但作为文档出现在数据字典中,如果某个派生列显示在ER模型中,则在这个名字的前面使用/来表明这个列式派生的,第一个步骤是检测逻辑数据模型的并产生一个包含所有派生列的列表。从物理数据库设计的角度看,将派生列存储在数据库中还是每当需要时再进行计算,需要进行一下权衡,为了确定哪个更好,应该考虑:存储数据的代价以及区维护它与派生数据的一致性代价,每次计算它需要的代价。根据性能的约束来选择一种代价低的方式。当系统的查询语言不能很方便的使用算术运算来计算派生列时,存储派生列是个不错的方法,表达派生列数据的设计应该完全记录在文档中,并且要记下选择某个设计的原因,特别是当有很多方法可以选择时,尤其要记下选择某个方法的原因。3.         设计其它业务规则。对表的更改可能会受到更改所表达的控制现实世界的事物业务规则的约束,因此必须设计域约束以及关系完整性约束,这个步骤地目标是设计应用到数据上的其它的业务规则,这些规则的设计同样不依赖于所选的DBMS,有些系统比其它的系统提供了更多的业务规则。而在一些系统中,可以使用触发器来加强约束,不要过多地考虑触发器的问题,创建业务规则需要注意以下的几个规则,确认字段规则,确认记录规则。确认字段规则可以保证输入到字段中的数据是正确的,字段规则用来检查用户放置到该字段的数据是否正确,如果输入的值违反了确认规则,将会显示所定义的提示消息。当保存一条完整的记录的时候,记录确认规则将起作用,与字段确认规则不同,记录确认规则可以引用其它字段,当你想比较表中的不同字段的值时,这是很有用的。例如记录一个还书日期的信息,其还书的日期不能比借书的日期更早。业务规则的设计应该全部存档,尤其是当有多种选择存在时,将选择其中的一种方法的原因记录下来。本文出自 “凌辉” 博客,请务必保留此出处http://tianli.blog.51cto.com/190322/59000... 全文

数据库 设计 ER模型 逻辑数据库

从需求出发来看关系模型与非关系模型–关系模型与非关系模型概述

自从NoSQL概念横空出世,关系数据库似乎就成了众矢之的,似乎一夜之间,关系数据库和SQL就成了低效,高成本,速度慢的数据处理模式的代名词。在很多地方都能看到类似:”我的项目初创,应该选择什么NoSQL产品才能快速的开发?”这样的问题。正因有人提出这样的问题,才坚定了我把这篇文章放在了第一章的决心。主要的目标是希望借助这样一个形式,让大家能够比较清晰的认识到类似NoSQL,SchemaFree,RDBMS,CAP,BASE等等概念的本源,并了解到他们面对的主要场景,从而避免乱花渐入迷人眼的尴尬,知其然而知其所以然。其实,软件中所谓的对象,结构体,实体,关系等概念,都只是对现实生活中的一种抽象。因为人类太过渺小,渺小到无法真正的理解和模拟这个世界,所以不得不创造出一些概念,过滤掉具体的细节而只关心他们所需要关心的事情。这就产生了各种各样的抽象。而SQL和关系模型,就是针对数据之间的“关系”而进行的一种抽象。简单来说,他将一切事物都抽象为关系,并通过集合运算的方式规定了关系之间的运算过程,也因此更为严谨。比如,描述一辆车有四个轮子和四扇玻璃,那么就可以建立三张表格,一张存车的属性,一张存玻璃的属性,一张存轮子的属性,并且在轮子和玻璃的表格中,冗余车的唯一标示。这样就可以完成关系描述。如果要读取车A.id=5车子的左前方轮子的出厂号码标示,做法一般是:查询轮子表,找到车子id=5的并且标有左前方属性的那行数据,读取他的出厂号码。了解了关系模型,我们再来看看在关系模型产生之前,大家经常使用的层次模型吧。层次模型其实也是非常简单的一类描述,还以车为例,一辆车有唯一的标示(可以是个id,也可以只是个入口引用),然后车节点有两个子节点,一个是轮子集合节点,一个是玻璃集合节点,然后,轮子集合节点有四个节点,分别表示四个轮子,而玻璃集合有四个节点,分别标示四扇玻璃。如果要读取车A.id=5车子的左前方轮子的出厂号码标示,做法一般是:找到顶节点车A,然后查找该节点的子节点,轮子集合节点,然后遍历4个子节点,找到标有左前方属性的车轮,读取其出厂号码。从上面简单的例子对比来看,相信大家立刻就能看出关系模型与传统的层次or表格模型的最大差别。也就是用户不再需要关注从车->轮子集合->轮子本身,这个存取路径只需要关注于核心的查询逻辑(车子id=5,车轮属性是左前方),就可以立刻找到数据了。使用关系模型,因为模型相对的比较简单,并且数学证明比较严密,所以很快被大家接受。因此在市面上已经很少出现层次模型or网状模型了。在互联网时代之前,数据库的研究领域更多的集中在关系模型与前端业务开发模型不匹配这个问题上,众所周知的,在面向对象的语言产生之后,继承,多态,充血模型已经成为了程序语言的标配,我们在这里不去讨论是面向对象好,还是函数式编程好这样没结论的问题,只来简单的浏览一下面向对象与关系模型的阻抗失配问题即可。如果大家写过业务逻辑,一定也会觉得把数据库里的数据转变为程序对象是一件蛋疼无比的事情吧。将面向对象里面的继承和组合这类概念硬套到关系数据库上,需要耗费比较大的精力才能完成。为了解决这些问题,一种思路是在程序层做这个ORMapping的转换,这类工具主要是hibernate、ibatis等工具。另外一个思路是在数据库层面做这件事,比如oracle一直宣传自己是ORDBMS。甚至甚至,连脚本语言框架比如ROR,django的核心目标之一也就是解决这个阻抗失配的问题~因为类似java/c++/.net这样的语言是静态编译的,所以就必须要求用户要在代码中明确的定义对象的属性名字和类型,而在数据库内,也有一套对应的列名和数据库类型信息。一张表有50多个字段,每次字段变更,都必须保证用户代码内的对象内的属性和数据库中的数据准确对应。这非常消耗时间,也非常容易错。为了解决这个问题,要么是从程序代码生成关系模型,要么是从关系模型反向生成程序代码。这两种方式都会面临程序逻辑与关系模型不匹配的问题,于是写ORMapping就成了一件蛋疼无比但又不得不做的事情。为了自动化,有大量的工具组件出现在这里,比如hibernate,比如ibatis,他们主要作用就是将我们的对象模型转换为关系模型,不过这类工具最大的问题就是,学习工具本身的成本很高,甚至高于自己去做对象关系映射本身,而且经常会因为对ORMapping掌握的不够精深,造成很多低效的查询,拖慢了整体性能的问题。还有一些人为了偷懒,放弃使用对象bean来表示数据库中数据。他们一般会采用Map映射来表示数据库中一行数据,使用这种方式,Map的key就是列的名字,value就是列的值,如果要表示多行数据,那么就是一个List<Map>的结构。使用这种结构,程序就可以自动的根据数据库给出的列名原信息来自动生成Map结构。但这种方式的问题是,丢失了面向对象所带来的良好的封装特性,经过多层传递与处理后,用户很难辨识哪些是数据中间过程数据,哪些是数据库原始数据。数据Map对象会膨胀的非常厉害,以至于无法管理。脚本语言的核心目标之一也就是解决这个阻抗失配的问题,脚本语言因为是动态编译的,所以动态对一个对象增加或减少属性变得非常简单而清晰,所以对象内的数据可以直接根据数据库内的数据进行内省获得,不在需要人工维护,同时又不会出现因为Map结构所导致的代码结构不清晰的问题,所以ROR这类的工具可以直接进行对象关系映射,极大地提升了小业务系统的生产力。可惜,对象数据库和xml数据库,都没有形成一统天下的新浪潮,一直不瘟不火的缓慢发展着。随着互联网的爆发式发展,数据库概念领域又一次发生了摇摆,伴随着互联网的特殊需求,一批有着新鲜血液的NoSQL数据库涌现了出来,层次模型又从封印中苏醒,站在了大家面前。这里就自然而然会有一系列的疑问产生了出来,为什么层次模型变种的NoSQL会出现并得到了一些人的认同?他满足了什么需求?关系模型在什么地方不能满足大家的需求了?那么,我们就从应用场景出发,尝试回答一下这些问题吧。... 全文

关系模型 NoSQL概念 对象数据库

详解Cassandra数据模型

Cassandra是一个开源的分布式数据库,结合了Dynamo的Key/Value与Bigtable的面向列的特点。Cassandra的特点如下:1.灵活的schema:不需要象数据库一样预先设计schema,增加或者删除字段非常方便(on the fly)。2.支持range查询:可以对Key进行范围查询。3.高可用,可扩展:单点故障不影响集群服务,可线性扩展。 我们可以将Cassandra的数据模型想象成一个四维或者五维的Hash。Column... 全文

Cassandra数据模型

JSON数据转化成模型

JSON数据转化成模型// 1.创建urlNSURL*url = kSUNUrl(@"video");// 2.创建requestNSURLRequest*request = [NSURLRequestrequestWithURL:url];// 3.发送请求数据NSOperationQueue*queue = [NSOperationQueuemainQueue]; [NSURLConnection sendAsynchronousRequest:request queue:queue completionHandler:^(NSURLResponse *response, NSData *data, NSError *connectionError) {         if(connectionError || data == nil) {         [MBProgressHUD showError:@"网络超时,请稍后..."];         return;     }     // 4.解析json数据     NSDictionary *dict = [NSJSONSerialization JSONObjectWithData:data options:NSJSONReadingMutableLeaves error:nil];     NSArray *videosArray = dict[@"videos"];     for(NSDictionary *dict invideosArray) {         [_arrayM addObject:[SUNVideoItem videoWithDict:dict]];     }     // 5.刷新表格     [self.tableView reloadData]; }];注意:在发送网络数据结束之后,一定要刷新表格。... 全文

JSON数据转化成模型

从需求出发来看关系模型与非关系模型–时代的变革

上回我们说到随着互联网的爆发式发展,数据库概念领域又一次发生了摇摆,伴随着互联网的特殊需求,一批有着新鲜血液的NoSQL数据库涌现了出来,层次模型又从封印中苏醒,站在了大家面前。这里就自然而然会有一系列的疑问产生了出来,为什么层次模型变种的NoSQL会出现并得到了一些人的认同?他满足了什么需求?关系模型在什么地方不能满足大家的需求了?那么,我们就从应用场景出发,尝试回答一下这些问题吧。提到NoSQL,自然而然就会有人问了,NoSQL是因为什么而被提出来的?又是因为什么而得到了一些人的认可呢?以及现在的演进状况如何呢?因为我也是部分的亲历者,所以就从我的视角,来回溯一下他们发展的整体的一个发展脉络吧。在这篇文章里,我将主要以例子的方式来做个回顾,以点带面以帮助大家对整个问题有更好的理解,对于一些细节性原理的阐述,我将放到后面的NoSQL章节里面做更深入和细致的剖析。记得那还是在08年的时候,我们这个中间件的team刚刚成立,它的目标是支持公司业务的高速发展的一些相对公用的组件。我也是刚刚加入其中。那时候大家更多地还是在努力的学习我们假想中的对手:ebay的架构。在ebay的整体架构设计词典中,使用最多的就是“异步”,“最终一致”,“幂等”这样的词汇。对于入行没多久的我来说,对这些词汇的本质含义还没有太多的认识,不过已经知道了原来网站的设计还真是个挺复杂的事情。在这些词汇中,“最终一致”是最让我困惑之一,我也算是学过数据库概念的人,虽然不管是不是死记硬背的,但一致性和隔离性的几个级别所产生的问题什么的还能基本知道,但突然来了个最终一致。。就让我觉得非常困惑了,他是什么?他和传统数据库的ACID有什么关系?坦白说这么多年了,我虽然对他们的认识有了更深一步的理解,但让我讲,我还真不一定能用很短的篇幅讲出来。。。不过我现在唯一能够确定的是,就算是在现在,你问1000个程序员,什么是一致性,估计能得到999种不同的回答,剩下的那俩回答一样的原因是因为搜索到了同一篇网页(笑)。而这也是当时国内外对网站架构的基本认识,因为在那之前,大部分网站主要的作用就是使用内容管理系统将编辑们发布的文章页面静态化然后给用户提供个评论窗口的程度而已。数据库有瓶颈的时候不多,有了加个cache大部分就都能搞定了,最多最多也只需要做个简单的数据库切分,一个拆几个,用户需求也就搞定了。对于高端一些的用户,则一般是使用从银行出来的方案,弄个运算能力超强,像小山一样的黑色柜子,然后再弄个放上几百块硬盘的大盘柜,也就解决了问题。能解决,但还是不爽,这些不爽主要是集中在这么几个地方:1.大型机技术被一些大厂把持着,定价权不在用户,购买的成本比较高,一般公司用不起。2.自己做数据库切分的话,碰到跨库join和跨库事务又不好处理3.数据库的灾备切换也是个头疼的问题,大家对数据安全性和性能的需求不一样,用同一个方案又不能都搞定。这些不爽其实直到现在都一直存在着,人类的发展历史,就是不断地针对不爽而逐渐解决的过程。但很多事情就是跷跷板,你压下了这头,那一头就抬起来,所以你看我们计算机的书里面讲某种算法的时候,是不是一般都按照这么个顺序来做介绍的:首先,告诉你一个场景,三种方法,A的好处是B的坏处,B的好处是A的坏处,然后权衡再三,选择了方法C。再想想,怎么跟富翁娶老婆,选了半天最后选了胸大的有一样的感觉呢?玩笑玩笑~其实这也就是我们去探索和解决问题的方式,或者说程序员在每天写程序的过程中其实就是在做一次又一次的权衡,甚至,你的每一个if,每一个else,都是在两种可能性中做出了选择~那么,当时为什么要做出这样的选择,就成为了问题的中关键的关键。技术的发展必定是依托于实际的需求的,就像富翁选择胸大的一样,在计算机的世界里,大家面临选择的时候也必定是从实际需求出发的。但是,很不幸的是,需求不可能都被满足,因为一些客观因素的限制,就不得不逼迫人类在两种痛苦中选择那个最轻的,而这“客观因素”也是我们未来将要关注的东西,我会尽我所能,在未来的文章中回答大家上面的这两个问题的。那么,我们就来看一看实际需求变化的情况,来把握当时选择的原因吧。在web2.0蓬勃发展之前,使用数据库的主要应用场景是个大企业,金融机构在使用,他们面临的主要问题是:如何高效简单的满足用户的需求,并且能够随着用户需求的变化而快速的进行响应。而对业务量上面的要求却并不夸张,大部分情况下,每天数据库也只需要处理不算特别多的用户请求。在这种情况下,开发的效率就成为了大家最为关注的目标,一切以开发效率为最优先选择的因素。那么,就让我们来看看,在数据库存储领域,有哪些东西是以提升工作效率为首要目标进行设计的。首先,关系模型就是其中之一,上篇文章我们也提到过了,关系模型主要的目标是”隔离了数据的存取路径,让用户只需要关心查询的逻辑”然后,事务和一致性的原理和实现机制是其中之二,为了事务和一致性读,数据库付出的代价是复杂的锁实现,开销也变得比较大。最后,约束(当然它也属于关系模型的要素,但实现上来说是分开的),也是为了方便和安全性而定义的性质好了,你可以看到,基本上来说,数据库做了这么多年,核心目标就是为了响应“当时”的用户更快而进行的设计,从而你也可以立刻理解在上篇里面,为什么数据库的开发人员投入了大量的资源在解决对象-关系不匹配的问题上,并产生了大量的ORMapping类产品的原因了。然后,互联网的时代到来了。互联网行业的蓬勃发展,对数据存储带来了新的要求,我们简单的列出来看看1.大量的用户2.单个用户的数据的价值非常低3.数据量比较大,部分数据增长较快4.用户的业务逻辑相对的比较简单对需求有了简单的定义以后,我们就来看看,传统的数据库与目前新的应用需求之间的关系,当然,我们这都是事后诸葛亮,在当时似乎没什么人能分析的这么清楚哈因为大量用户,并且单个用户的数据的价值非常低,所以自然的,在大部分应用上使用大型机和盘柜就明显不理智了,你用这玩意儿去存哪些用户点了“喜欢”?或者用这玩意去存哪些用户今天吃了竹子,明天吃了牛排?因此,一些大厂在之前的积累,与目前新价值产生的领域出现了不匹配。所以,开源的mysql就成为了大量从LAMP架构成长起来的互联网企业的首要选择,在他们成长为大网站的时候,大量的数据存储需要以相对安全的方式进行扩展,因此,针对mysql的切分自然就成了大家的首选方案之一。包括facebook,淘宝,甚至google在内的大量互联网企业基本都选择了使用mysql进行切分的方案来构建他们的业务系统,以满足不断上涨的用户量。既然选择了数据库切分,那么我们自然要分析一下,数据库切分能做到什么,不能做到什么。数据库切分的最大优势,是对之前的架构冲击不大,因为切分逻辑是很简单可以写出来的,而既然之前能够接受mysql所提供的安全性标准,那么水平的扩展更多的mysql,安全性标准基本没有发生变化,不需要担心架构和人才出现不匹配的情况,该踩的坑都大部分都踩过,社区比较大,问题能够快速得到解决。因此,这是目前而言最理智的选择之一。但数据库切分也不是没有问题的,而且问题很多很多。。首先,最大的问题就是业务要做重构,原来用单个数据库的时候,业务里面经常能看到多条更新的事务操作。这些操作中有不少,在数据库切分之后不能够直接运行在多台机器上,当然,有些人会反驳说:谁告诉你不行的?2pc知道不?coodinator,cohorts知道不?谁说不能做!?—我的回答是,嗯,能做,但不可能能以单机事务那样的成本做到。甚至,在大部分场景下,你会因为延迟难以忍受而不得不放弃原来的事务操作模式。啊!好痛好痛,我的膝盖中了一箭!~然后,运维和管理难度上升了,原来只有一个机器的时候,运维虽然也苦逼,但相对的没有那么苦逼。而现在,一个应用就有100多台库,假设一个在一年内挂掉的概率是1%,那么如果他们都是独立事件,100台里挂掉1台的概率是63%。扩容也是问题,怎么扩,如何扩,都是需要解决的问题。啊!好痛好痛,另一条腿也中了一箭!~最后,关系模型也成了累赘,原来的俩表join,现在你变成了俩库的join,做是能做,延迟得考虑吧?性能得考虑吧?数据量也得考虑吧?就算是log2N的二分查找,N=1000和N=100000000000在查找效率上还是有一定差别的吧。老的解决方案里存在这样和那样的问题,看起来似乎都有点棘手和难以解决。所以,时代需要新的声音,破坏与重新构造,成为了数据存储领域的主音。然而,在如何破坏与如何重新构造这个问题上,大家产生了分歧,就像历史上无数次的政治风暴一样,有些人向左,有些人向右,更多的人困惑的站在了原地。下一篇,就让我们来感受一下时代的脉动,真正的进入存储领域的战国时代吧。... 全文

关系模型 数据库切分 非关系模型

PowerDesigner导入SQL生成数据模型

    项目数据结构没有。需要自己来进行建立,于是把数据库的结构导出成了.SQL文件,然后再导入PowerDesigner进行处理,方法如下:        1、启动PowerDesigner,选择"File"菜单中的Reverse Engineer->Database    2、选择你的DBMS类型。点击确定    3、选择"Using script files"并选择你的SQL文件。点击确定。... 全文

files 数据库 模型 项目

【ZooKeeper Notes 14】数据模型

转载请注明:@ni掌柜 nileader@gmail.com 本文主要讲述ZooKeeper的数据模型,包括ZooKeeper的数据视图,节点的层次结构以及节点类型等基本属性。Zookeeper的视图结构类似标准的Unix文件系统,但是没有引入文件系统相关概念:目录和文件,而是使用了自己特有的节点(node)概念,称为znode。Znode是ZooKeeper中数据的最小单元,每个znode上都可以保存数据,同时还可以挂载子节点,也构成了一个层次化的命名空间,我们称之为树。... 全文

节点 zookeeper znode 数据模型

建立安全模型 保障Web数据库安全运行

随着Web数据库的应用越来越广泛,Web数据库的安全问题日益突出,如何才能保证和加强数据库的安全性已成为目前必须要解决的问题。 数据库系统安全控制模式 Web数据库是数据库技术与Web技术的结合,其中存在诸多安全隐患,如通过网络传输的用户名和密码很容易被人窃取。用户读取的数据可能被截取、篡改等。如何保障Web数据库的安全运行呢?建立安全模型通常,安全措施是计算机系统中用户使用数据库应用程序一直到访问后台数据库要经过的安全认证过程。... 全文

安全 模型 Web 数据库

从需求出发来看关系模型与非关系模型–时代的变革1

上次我们谈到,因为互联网应用的实际需求与传统数据库之间出现了不匹配的情况。 于是,破坏与重构就成为了新时代的主音。对互联网应用而言,最急需的需求,就是处理大量用户输入的海量数据,进行一些逻辑处理后再将结果返回给用户。因此,对于在线数据处理来说,可水平扩展的容量指标,可无限增长的写入tps和读取qps,是互联网企业的最大,最急需的需求。... 全文

从需求出发来看关系模型与非关系模型 破坏与重构 数据总线

怎样用Oracle的ODP.NET创建实体数据模型

在VS2010开发环境中,建议采用第三方插件连接数据库,而不再提倡用微软自带的Oracle连接工具。第三方插件有很多,例如dotconnect for oracle,ODP.NET等等。本文我们就用Oracle自家的ODP.NET来连接Oracle数据源,现在ODP.NET也可以支持实体数据模型(Entity Framework)。... 全文

ODP.NET Oracle 实体数据模型

Thinking in BigDate(13)大数据之DM经典模型(4)

    文章的立足点,不是基于数据挖掘的算法,和一些详细的算法实施。在读一些大牛的博客中,这方面已经写的非常详细,但是我们一开始看到这的纯技术的博客,一些公式,一些算法,难免吃力。所以前期,有一个整体概念上的疏导是很有必要,对那些想在数据挖掘下点功夫的人,是一件很好的事情。其实我们的困惑是不知道它能做什么,这就是为了开始知道它能做什么而准备。      ... 全文

数据挖掘 模型 统计学 概率

大数据:“人工特征工程+线性模型”的尽头(1)

标签:大数据机器学习特征工程11年的时候我加入百度,在凤巢使用机器学习来做广告点击预测。当时非常惊讶于过去两年内训练数据如此疯狂的增长。大家都在热情的谈特征,每次新特征的加入都能立即得到AUC的提升和收入的增长。大家坚信特征才是王道,相信还会有源源不断的特征加入,数据规模还会成倍的增长。我也深受感染,坚定的相信未来两年数据至少还会长十倍,因此一切的工作都围绕这个假设进行。现在两年过去了,回过头来看,当时的预测是正确的吗?... 全文

大数据 人工特征工程 线性模型

Thinking in BigData(14)大数据之DM经典模型(5)

     接着上篇文章,接下来我们将探讨朴素贝叶斯模型、线性回归、多元回归、逻辑回归分析等模型。4、朴素贝叶斯模型       表查询模型简单有效,但是存在一个问题。随着输入数量的额增加,每个单元格中训练样本的数量会迅速减少。如果维度为2,且每一维有10个不同的变量,那么就需要100个单元格,而当有3个维度时,就需要1000个单元格,4个维度就是10000.这样成指数级的增长,哪怕的传统数据挖掘中都会遇到明显瓶颈。... 全文

数据挖掘 统计学 模型 业务流程

osi七层模型

OSI七层模型物理层:在设备之间传输比特流。指定电压大小,线路速率和电缆的引脚。数据链路层:将数据包组合为字节,字节组合为帧。使用MAC地址提供对介质的   访问。执行差错检测,但不纠错。网络层:提供网络寻址,以便路由器进行路由选择。传输层:提供可靠或不可靠的传输。在重传前执行错误纠正。会话层:维持不同应用程序的数据分隔表示层:表示数据,处理数据。处理数据,比如加密。应用层:提供用户接口DOD模型网络接入层因特网层主机到主机层过程/应用层  TCP/IP 数据段格式                                                       位15 位16   源端口号(16)                                      ∥  目的端口号(16)                                              序列号(32)                                           确认端口号(32)       头长度(4)∥ 保留(6)|   代码位(6)∥                               窗口(16)       校验和(16)                                         ∏                              紧急(16)                                        选项(0或32,若有的话)                                                   数据(可变) 本文出自 “千回百转” 博客,请务必保留此出处http://lixuebin.blog.51cto.com/543609/347697... 全文

休闲 osi七层模型 DOD模型 TCP/IP 数据段格式 职场

活的大数据实战——人群标签及标签关联性挖掘(1)

2013年初,第85届奥斯卡金像奖颁奖礼在美国好莱坞举行。而在颁奖礼之前,微软纽约研究院经济学家David·Rothschild通过大数据分析,对此次奥斯卡各奖项的得主进行了预测。结果显示,除最佳导演奖有所出入外,其它各奖项全部命中。这并不是David第一次准确预测,在2012年美国总统大选中,他就曾准确预测了51个选区中50个地区的选举结果,准确度高于98%。... 全文

大数据 大数据实践者 数据模型 数据关系

1 2 3 4