数据库界的四位图灵奖得主(二):解决科学问题才是硬道理
作者:波罗
前言
原拟名《梅花香自苦寒来,关系库从磨难出》,以突出E.F.Codd经历的困难,近日连开两个973项目交流会,换场期间,有朋友建议把最后的小标题升为大标题,以突出其贡献,也合今天973 基调;此外,第一次在北京机场发博文,匆忙之中,如有错漏,请及时提醒。
功过从何数
1981年,58岁的E.F.Cood 获得图灵奖,这是数据库界的第二枚(也是久违了的)图灵奖。从1970年提出关系数据库到获奖,奋斗十一年,终成正果。如今,斯人已驾鹤西去,回望其成功之路,不禁想起了电视剧《西游记》取经成功后的插曲《青青菩提树》:
几多朝朝暮暮,漫漫云烟无数,…..
历经坎坷终无悔,未教年华虚度…..
面对大千世界, 功过从何数? ……
好,现在就来数一数。
网上传统传记太多,这里想写一篇不很传统的、轻松一点的描述,须从数据库的型与值说起。
数据库的型与值
模型和模特儿在英语中是同一个单词model,其实,译音又译意的“模特儿”既通俗、又朴素,也最直白地说清楚了高雅的“模型”在数据库中的的含义,模型就是骨架。且看图:
上图中,左边的模特, 抽象一点,不过八两铁丝,一些手艺;披上了衣服后,加上想象,就有了的美感、就产生了价值或数值;用计算机专业的行话,左边是“型”,右边是“值”。
其实,模特不必升级为活生生的美女靓男,那不过增加了若干不必要的语义,商业的,心理的,展示的,诱惑的,等等,目的是 买家买家快掏钱,而过分的“型”,可能干扰对“值”的评价,
下图中 ,左上是一个层次库模型。左下是其对应的库值。它是上文提到的网状数据库模型的特例,只不过比网状模型上多了一条限制——每个节点至多一个父节点。
右边是关系模型,我们凡人,熟视无睹,看千遍,也不一定能看出是图灵奖的素材。
关系数据库的传奇
笔者有个奇怪的(穿越的)感觉,旋律优美的歌曲《传奇》适合用来赞颂E.F.Codd对关系模型的衷情和忠诚,试看下面的分段演绎:
《传奇》:“只因为在人群中多看了你一眼,再也没能忘掉你的容颜,…..”,
在E.F.Codd考查二维表格之前,成千上万人早就观察过,可人们都熟视无睹,擦肩而过;
唯有E.F. Codd,在1970年的某一天,在人群中多看了它几眼, 奇迹发生,“来电了”!
于是他投入心血,把对表格的那份情有独钟,发表在《Communication of the ACM》,其标题为 “A Relational Model of Data for Large Shared Data Banks”。
此文在集合论的严格数学基础上,建立了关系数据库模型;仅仅是上图的框架,还不能称为模型。通常:数学模型 = 一个集合+一组符号+一组规律(如交换律、结合律)+ 一组性质(定理);如群环域是从现实对象中抽象出来的代数系统(数学模型的一类)。关系模型,关系代数也是数学模型。
E.F.Codd一发而不可收,接下来,有一系列文章发表; 那几年,关系模型成了E .F. Codd 心中的那个“她”。今天,人们还可以追踪他和”她”的故事:
为了她的数学美,他用范式理论为她浓妆,因为她憔悴,他用12条准则为她粉黛……
《传奇》: “宁愿用这一生等你发现,…,今生的爱情故事不会再改变。”
接下来,E.F.Codd的路上,少有鲜花,多有荆棘。
1983年,笔者到美国学习数据库,导师为鼓励我们克服困难和坚持学术观点,说,E.F Codd 也曾遭遇到压力山大,以至于影响健康,还进过医院;又说,要学习他不怕困难,坚持自己认为正确的学术观点,最后冲出重围,….,
但语焉不详,可能是有一些难言的细节。由于人们不太愿意多写尴尬事,现在网上仅仅能查到一些蛛丝马迹。例如下列的”但书”:
…..但是,有人认为,关系模型…..是理想化模型,…..不现实…,担心性能难以接受;
有人视其为(当时正在进行中的)网状数据库规范化工作的严重威胁….
日子艰难了,就觉得时间慢,但E.F.Codd坚持着, 就像《传奇》唱的“宁愿用这一生等你发现,…,今生的爱情故事不会再改变….”。
又是五个春来秋去,终于迎来转机。
明争取代暗斗 1974年ACM牵头组织了一次有思想交锋的研讨会。
正方:E.F.Codd及其支持者;
反方:Bachman及其支持者;
Bachman何许人也?就是上篇博文主人公,数据库界第一个(当时唯一的)图灵奖获得者。轻量级对重量级,E.F.Codd能坚持得住吗?悬念…
幸好,E.F.Codd足够坚强,坚持下来了。这次的辩论改善了作为新生事物的关系数据库的生存环境,推动了关系数据库的发展。
花香墙外,嘴仗结束,新技术的美妙吸引了新的IT人;虽然,知识有产权,但本质上,知识是人类共创共享的(当然,在一定法规下)。
世界上不乏有眼光,有胆略的人,拉里.埃利森及其团队就是典型,他们认定关系数据库的前景,在1977年建立一个新的小的公司,实现了第一用商用关系型数据库管理系统,后来发展成为Oracle。
当墙外花香日益浓厚,大赚其钱的时候,IBM才发现自己有点亏,才承认关系数据库的确好,急起直追研发DB2等等。
以后的事实表明,关系数据库易学易用,基础坚实,理论丰厚,用户不需知道存储结构细节(用今天关于“透明”的时髦术语,有结构透明性),终于让网状数据库和层次数据库(保留了历史地位)退出了历史舞台,RDB登堂入室,成为现代数据库产品的主流。
亲历过对比,才有发言权 在关系数据库还没占绝对优势的岁月里,笔者参加过几个网状数据库和层次数据库的应用项目开发,几年的编程生涯,熬夜多,得意少,磋磨多,顺风少;因为最终应用是给非计算机专业人员用的,写了很详细的说明书,最终用户也不是很轻松;后来那些程序,都移植到关系数据库了,相关人员用后,高兴得要唱“解放区的天”。
生不逢时还是官僚主义? E.F.Codd是IBM的人,做的是IBM的成果,IBM 启动了关系数据库验证项目System R, 但没有优先的支持,一直到1980年System R才作为一个产品正式推向市场。有人分析System R产品化缓慢的三个原因:
1)IBM重视信誉和质量,为尽量减少故障,所以慢(精工出细活);
2)IBM的官僚主义,错失了一次发展机会。(到处有官僚主义,官僚主义有时也成为检讨中的替罪羊);
3)IBM当时正改进层次数据库产品,如果把层次数据库IMS比喻为周瑜,把关系数据库比喻为诸葛亮,所以有点像(与传统 略有不同)“既生亮,何生瑜?” 所以关系库在IBM内生不逢时。
数学美进入了数据库 E.F.Codd的理论,给数据库领域带来了数学美;
例如,用于函数依赖推演的Armstrong 推理竟然是Sound(可靠)且complete(完备)的!, 不少数学系的博士生在寻找博士后岗位时,选择了数据库。
又例如,用于设计一个好模式的规范化理论,从一阶范式到三阶范式,很快变成了程序,在实践中收到欢迎;而且,还有 4阶、5阶,…,N阶范式,吸引人的魅力在于,不知还有多少可探的宝藏,不知将有多少博士和副教授在这里成长!
一大批数学人才转业到数据库理论方向,一时间,关系数据库理论人才济济,风生水起,成果累累….
“过度追求数学美”不是Codd惹的祸。但是,过度追求数学美的坏习惯也趁机进入了数据库领域(或计算机领域),有人研究了规范化理论的5NF、6NF,据说还有(毫无用处的)7NF、8NF、9NF !
在私下议论时,同行们还批评过若干过度追求数学美的例子(不适合上网)。计算机科学为计算而生,为计算而发展,是实践性很强的学科。
E.F.Codd的数学工底很好,但他十分强调实践,强调应用;(可能在1974年那场ACM组织的大辩论中,他也受益于反方强调应用的观点)。综观他的生涯,可以确定,“过度追求数学美”不是Codd惹的祸。
解决科学问题才是硬道理。上世纪70年代,关系数据库将生未生,数据处理领域遇到了下列科学问题:
(1)网状数据库后的下一代数据库是什么,数据库向何处去?
E.F.Codd回答:下一代将是关系数据库模型,并用集合论的语言给了坚实的基础和眼睛的描述;
(2) 如果用关系数据库,什么是好的关系数据库模式?怎样设计一个好模式?
E.F.Cod及其跟随者给出了规范和理论和一系列设计好模式的算法
(3)怎样使关系数据库管理系统多、快、好、省?
E.F.Cod给出了十二条准则,及若干研究。一大批追随者办公司,提方案、作设计、写程序,实现了关系数据库系统。
三个科学问题的提出和解决,当然不是E.F.Codd一人的功劳,但他是斗士、是先锋,在其中起了关键作用;图灵奖给他,正当其人,实至名归。
上篇博文问,多少论文才得得到图灵奖,Bachman的例子说明,图灵奖与论文篇数没关系,或没多大关系;而E.F.Codd的例子说明,想得图灵奖,提出科学问题、凝练科学问题、解决科学问题才是硬道理。
想借用牡丹之歌 如果某一天,我和我的朋友们,有机会到E.F.Codd 墓前吊唁,怀念数据库界的这位前辈大师,我想在《牡丹之歌》中抽样地选出几句, 写在白牡丹扎成的花圈上:
有人说你富贵,
哪知道你曾历尽贫寒……
春风吹来的时候,
你把美丽带给人间…….

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
-
上一篇
PostgreSQL与MySQL的对比与选择
作者:波罗 前言 PostgreSQL:PostgreSQL比MySQL提供更多的功能和可扩展性。PostgreSQL旨在从一开始就提供MVCC(并发交易)和ACID合规性。它与最广泛的NoSQL格式兼容,并以管理大型数据集上复杂分析过程的最佳解决方案而知名,它特别擅长处理并发读写操作。目前已经是替换Oracle的开源数据库最佳选择 。 MySQL:MySQL的功能少于PostgreSQL,但这使MySQL可以专注于系统稳定性和处理速度(特别是对于只读查询)。MySQL以提供最佳网站解决方案和进行在线交易而著称,同时与各种可插拔数据存储引擎兼容。 功能、特性对比 PostgreSQL是一个高度可扩展的数据库管理系统,作为对象关系数据库管理系统(ORDBMS),PostgreSQL具有对JSON,XML,带有HSTORE的键-值对的本机NoSQL支持,并且它允许对JSON数据建立索引以加快访问速度。这使得PostgreSQL在处理不适合关系格式的数据时成为一种流行的选择。 PostgreSQL是最稳定,功能最丰富的开源RDBMS之一。在实施复杂的查询时,它的性能很好。将其它数据库转换为P...
-
下一篇
YARN——队列内的优先级调度
【原理介绍】 在hadoop官方文档中,描述了容量调度支持按任务的优先级来调度。 具体来说就是:客户端向yarn提交任务时,可以指定任务的优先级。任务的优先级是一个正整数,值越大意味着任务的优先级越高;在容量调度的队列中,对任务按优先级进行排序,优先级越高的任务,会优先进行资源的分配。 不同类型的任务在提交时,通过不同参数指定优先级,但基本上大同小异,例如: MapReduce "-Dmapreduce.job.priority=xx" Flink "-yD yarn.applicaiton.priority=xx" Spark "spark.yarn.priority=xx" 注意:spark的参数在3.0版本后才引入使用 既然任务提交时,优先级可以通过参数指定,那么如果没有指定优先级,是否会有对应的默认值呢?答案是肯定的。 在yarn中,任务的优先级有两个维度配置:一个是全局最大优先级,一个是队列默认优先级。 队列中任务的默认优先级在配置文件capacity.scheduler.xml中进行配置,例如: <property><name>yarn.schedu...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- Dcoker安装(在线仓库),最新的服务器搭配容器使用
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7,8上快速安装Gitea,搭建Git服务器