数据规范化反思,第 1 部分: 业务记录的历史

检查计算机系统中保存的记录

关系数据库成为业务系统的基础已有超过 25 年的时间。数据规范化是一种方法,可以最大限度地减少数据重复,保障数据库不会出现数据异常等逻辑和结构性问题。在大学中一直保留着关系数据库规范化这门课程,并且数据库规范化也得到了广泛的应用。规范化是在 20 世纪 70 年代制定的,当时对计算机系统的设想与如今的计算机系统完全不同。

本系列分为两部分,第一部分针对保存在计算机系统内部和外部的记录进行了历史回顾。基于这样的背景,本文将探讨与数据规范化有关的问题,例如,在不断变化的世界中将业务记录映射为规范化数据的复杂性和难度。然后,第一部分还将讨论非规范化的情况,并介绍 World Wide Web (万维网)如何影响非规范化业务记录的创建和交换。本系列的第二部分将讨论可以克服规范化问题或引入架构灵活性的其他数据表示方式,如 XML、JSON 和 RDF。

Susan Malaika, 资深技术人员, IBM  

Susan MalaikaSusan Malaika 在 IBM Information Management Group 工作。她的专长包括 XML、Web 技术和网格计算。她与人合作出版了关于 Web 的专著,发表了关于 Web 的文章。她是 IBM Academy of Technology 的成员。



Matthias Nicola, 高级技术人员, IBM  

作者照片:Matthias NicolaMatthias Nicola 是位于加州圣何塞的 IBM 硅谷实验室的一名高级软件工程师。他的工作重点是 DB2 性能与基线、XML、临时数据管理、数据库内分析及其他新兴技术。Matthias 与客户和业务合作伙伴紧密协作,协助他们设计、优化和实现 DB2 解决方案。之前,Matthias 曾在 Informix Software 公司负责数据仓库性能方面的工作。他从德国的亚琛科技大学获得计算机科学博士学位。


developerWorks 投稿作者

2012 年 3 月 05 日

免费下载:IBM® DB2® Express-C 9.7.2 免费版 或者 DB2® 9.7 for Linux®, UNIX®, and Windows® 试用版
下载更多的 IBM 软件试用版,并加入 IBM 软件下载与技术交流群组,参与在线交流。

简介

本文介绍数据规范化 [30] 在商业系统中的角色转变。自 20 世纪 70 年代数据规范化被定义以来,计算机技术和信息系统及其应用程序已有相当大的发展。特别是,在 20 世纪 70 年代,虽然数据结构很稳定,但磁盘空间是极其有限的,而且业务信息保存在纸质文件中。需要员工和输入输出设备将纸质文件转化为计算机可以读取的形式,例如,穿孔卡片。银行等大型机构所拥有的大型计算机只有 512K 内存,但成本却接近 2,000,000 美元。一个大型机构用 10 兆字节的磁盘空间就可以保存其所有计算机系统和数据。在 20 世纪 70 年代,Internet 基础架构才刚刚开始建立,而 World Wide Web (万维网)在十多年后才出现。

由于磁盘空间极其有限,因此仅存储最新的信息并提供给应用程序使用。规范化确保每一块数据(如姓名、地址或订单信息)在磁盘上只出现一次,以避免数据异常并保留更多的空间。通常情况下,规范化数据只存在于计算机系统中,并且与数据的原始业务表示并不一致。在 21 世纪,业务数据几乎总是以数字形式创建,如在 Web 服务请求中的订单消息。因此,规范化意味着,现有业务记录的数字表示被拆分,以便将数据存储在数据库中,然后重构它们,从而实现这些业务记录的演示和消费。

在本文中,“业务记录” 一词用来表示在两个或两个以上当事人或组件之间共享的信息,如采购订单、收据、缴款通知书、金融交易、银行转帐、保险政策、电子邮件、患者记录、日志记录、测量、记录的事件、强制性的政策或法令,等等。

作为关系模型的基础的假设已发生了变化。如今,许多系统和信息结构不再是简单和固定的,而是复杂和迅速变化的。在当今世界,进程的规范化对于敏捷系统的交付和系统的敏捷交付可能都是一个制约因素。

本文介绍计算机投入商用前后的记录保存历史。人们观察到的一个很重要的现象是:在整个过程中,业务记录都按 “原样” 存储,计算机的引入只是促使记录分裂成多块(规范化)。然后,本文会研究在 20 世纪 70 年代制定数据规范化的动机。随后,本文会解释某程序的数据 规范化如何成为一种普遍应用的妥协。最后,本文将讨论 Web 对业务记录的影响,这使人们能够将它们创建为数字格式,从而首次实现了在计算机中以其 原始结构来存储和处理业务记录。

记录保存的历史

本节将介绍在推出计算机之前的记录保存的某些方面的信息,帮助我们了解计算机所带来的显著变化。稍后就会在本文中描述这些变化。

已发现的收据可追溯到公元前三千年的古代苏美尔 [‎1],当时是先交换粘土片,然后保存这些粘土片来保存记录。巴比伦的贷款记录可追溯到公元前 18 世纪 [‎2]。巴比伦(公元前 1792 年)的汉穆拉比法典 [3] in Babylon (1792 BC) 中包括监管记录(粘土片)的处理和保存的条款。例如:

  • 如果有人欠贷款债务,而风暴吹倒了粮食,或粮食失收,或由于缺水导致粮食不生长;在这一年,他不需要向他的债权人缴付任何粮食,他可以用水洗掉他的债务粘土片,并且不需要支付当年的租金。
  • 如果有人向免役税(因为无法支付税款或租金而被剥夺所有权)的酋长、男人或个人购买田地、花园和房子,那么应当打碎他的买卖合同粘土片(宣布合同无效),并且他会损失他的钱。田地、花园和房子也将归还给其业主。

在历史上曾引入过多种机制来记录交易信息,比如理货筹码 [‎4][‎5],它比纸张更便宜并且更容易获得。在中世纪的欧洲,筹码上刻上凹槽标记,然后纵向劈开。两部分都有相同的槽口,交易的双方会收到半根标记过的筹码作为证明。然后将这些筹码保存并进行保养。英国政府直到 1826 年还在使用劈开的理货筹码来管理税收。理货筹码存储在 1834 年被下令销毁,因为已出现了更现代的记录方法 [‎5]。

直到 20 世纪末,纸和更早期时使用的莎草纸和牛皮纸 [‎‎6],在多个世纪中越来越多地用于记录业务交易、销售票据、合同和其他重要文档。通常情况下,记录会被签署,有时会用蜡密封,并盖上相关商家的标记。在 15 世纪引入了如双簿记等方法。办事员和文员用越来越多的文书工作来支持商家。计算机在 20 世纪投入商用,于是一些企业开始实现系统电算化,这需要将现实世界中的纸质记录转换成计算机可以理解的表示方式 [‎‎7]。

在引入计算机之前,保存记录的主要原则是:获得和保持参与交易的各方之间所交换信息的完全相同的副本。通常情况下,会采用某种方式对记录进行签署或标记,并以 “原样” 存储,以满足未来的需求。历史上一直都有管理业务记录与合同的存储和处理的规则。

计算机系统中的记录保存

本节介绍在二十世纪下半叶,引入数据库系统时的环境,以及这些系统的主要作用。

由于在 20 世纪 50 年代和 60 年代引入了数字计算机系统来支持商务业务,第一个记录被保存在穿孔纸卡 [8]上,穿孔纸卡也往往被用于输入和输出。人类操作员将代表业务交易的纸质记录的内容输入到卡上,使计算机可以读取和使用这些信息(图 1)。尽管计算机系统内存储和处理的数据在穿孔卡时代还可能与数据输入电脑的方式相匹配,但它已无法再与纸张上的真正业务交易相匹配。

图 1. 在 20 世纪 50 年代的数据录入人员
人们坐在键控穿孔机前

直到 20 世纪 80 年代,穿孔卡仍然被大量用于计算机系统的数据输入和输出,但在 20 世纪 60 年代,磁带 [9] 和之后的磁盘存储 [‎10] 很快取代了大型系统中所使用的穿孔卡。随着磁盘存储的出现(图 2),直接迅速的数据访问成为可能,因为磁盘的各个部分都可编程寻址。在磁盘出现之前,大多数处理是分批 [‎11] 进行的,数据按其在磁带或穿孔卡上的文件中的存储顺序接受处理。而磁盘则实现了随机的数据访问。

图 2. 在 1956 年装运一个 5MB 的 IBM 硬盘
非常大的硬盘

在 20 世纪 60 年代,人们开发出了一些数据库系统 [‎12] 和直接访问文件系统 [13],用以管理存储在磁盘上的数据,利用新出现的磁盘存储,使得多人可以同时访问和更新这些数据。当时两个最常用的数据库结构是网络模型 (CODASYL) [14] 和层次模型 (IMS) [‎15]。在将数据存储到数据库和执行应用程序之前,先由专业人员(数据分析员或数据库管理员)进行数据设计,将业务数据(在那个时代,业务数据仍然保存在纸张上)解构为层次或网络。分析员开发了两个数据设计模型,一个是逻辑设计,将业务记录映射为程序员可以访问和操作的层次或网络;另一个是物理模型,将层次或网络映射到磁盘。程序员学习逻辑模型,并通过随数据库系统提供的导航编程接口访问数据库(例如,获取父数据内的下一个子数据),这些数据库使用当时流行的编程语言编写。

在 20 世纪 70 年代,推出了取得巨大成功的关系模型 [‎30],在 21 世纪,它仍然称霸业务系统。它在表中存储业务数据。关系模型中消除了导航访问的需要,但仍需要进行数据分析,将业务数据解构为程序员通过声明式语言 (SQL) 访问的表格。在 20 世纪 70 年代和 80 年代,业务数据仍然是基于纸张的,并且必须对它们进行转换,这种转换往往通过扫描仪或操作员重新打字的形式完成。业务数据的解构通常要遵循数据规范化的原则 [‎16] [‎17],这些原则在 21 世纪仍然在传授和使用,以尽量减少数据的重复和异常。

在定义关系数据库的概念的时候,其中一款流行的磁盘存储设备是 3330 model 11,它的容量为 200 兆字节,其购买价格范围在 $74,000 至 $87,000 (20 世纪 70 年代,美元)之间 [‎19]。关系型数据库在 20 世纪 80 年代开始飞跃发展,当时流行的磁盘是 3380。它的大小相当于一个衣柜,存储容量为 1.2 千兆字节,成本超过 200,000 美元 [‎20]。因此,1MB 的磁盘存储成本超过 160 美元(20 世纪 70 年代),这些钱在 2010 年相当于数千美元 [‎21]。

通常情况下,关系型数据库系统并没有维护与签名相关的安全信息,并且,任何信息片段通常都只保存一次,即只保存最新版本,这使得很难对其执行审计。因此有必要存储现实世界的业务记录的副本,这个需求很快就变得显而易见,例如,在出现纠纷时,要能够审核保险政策和相关的索赔。法规要求业务数据必须保存若干年,为了遵守该要求,则需要使用文档系统。在 20 世纪 80 年代后期开发了一个新的软件类别,它被称为 Enterprise Document Management Systems (企业文档管理系统) [‎23],用于存储纸质记录的图像。这些系统独立于将相同的数据存储在关系表中的数据库。在 21 世纪,Enterprise Document Management(企业文档管理)被称为 Enterprise Content Management (企业内容管理) [‎24]。

在 20 世纪时,在电脑内的记录保存的主要原则是,引入一个适合计算机工作方式的存储模型,任意给定数据项都只存储一次,这最大限度地减少了存储量。如果需要一份完全相同的真实纸质记录副本,就要建立单独的系统来实现,这导致相同的数据被存储多次。监管记录的存储和处理的法规也在不断增加。

数据规范化过程

本节将介绍数据规范化过程的目的和效果,数据规范化过程首次引入于 1970 年,在 20 世纪 70 年代,引入了更多的规范形式。

数据规范化是一种方法,制订在数据库中代表现实世界的业务记录的表集,以避免任何数据重复,因为存储很昂贵。避免数据重复也意味着不会发生更新异常。关于数据规范化的记载非常详细且广泛 [‎18]。它从一个大表开始,该表代表现实世界的业务记录的所有属性及其主标识符(键),然后删除层次结构(重复的组)以简化 SQL 等语言的查询。还将删除结果表中必备的所有重复数据和函数依赖关系。

为了实现规范化,表示所有必需属性的单个表被分成通过主键和外键链接的多个表。数据规范化的结果是,单个业务记录可以使用几十个表,有时甚至使用上百个表来代表一条记录。此时引入了许多人造键(以及相关索引),它们在现实世界中并不存在,但需要使用它们来重构现实世界的业务记录。如果存储多个版本的业务记录(例如,订单,然后是对订单所做的任何修改),则需要对所有涉及的表进行版本管理,这使得表的查询和维护更为复杂。有一种替代方法可以节省存储空间,该方法只存储增量,而不级联各个表的完整版本,这为程序员带来了更多的复杂性。

在 1980 年,2MB 的存储成本大致相当于美国的计算机程序员一周的工作成本 [‎19][‎22]。在 2010 年,即使 1GB 的存储空间也只相当于极短的时间成本,甚至抵不过计算机程序员的几分钟,并且存储的价格在持续下降。此外,内存变得充足,I/O 操作的成本(延迟)也在不断下降,因为正在推出固态硬盘等新存储类型。除了关系数据库之外,存储介质通常用于存储非规范化项目,例如文件服务器、Web 服务器、内容存储库、应用程序服务器中的项目等等。

将关系存储与引入计算机系统之前用于记录保存并始终按 “原样” 存储的粘土片、理货筹码、纸质记录进行对比。出于存储的目的,它们并没有打破或转换为不同的格式,其原因有几个。首先,存储空间通常很充足,并不需要节约空间。其次,这些项目的任何转换(和重构)本来都非常昂贵。第三,以原来的形式存储这些记录的好处是,当从存储中检索它们时,就可以很容易地使用和理解它们。同样的理由也适用于如今以非规范化的形式存储的实际的数字业务记录,本文后面会讨论这一点。

由于纸质记录的使用在 19 世纪和 20 世纪迅速增加,存储空间成为让一些图书馆和档案馆头疼的问题。这引发了缩微胶卷和缩微胶片的发明,将所需的存储空间减少为原始材料的 0.25% 到 3% [‎25]。然而,这只是一种压缩形式,并没有采用不同概念的方式来表示信息。同样,如今可应用数字压缩技术来减少非规范化业务记录的存储消耗。

在高昂的存储成本的推动下,数据规范化在计算机中对业务记录的表示方式是,将记录解构为许多个部分,有时是几百个部分,然后根据需要再次重构它们。这需要使用人造键和关联的索引,将单个记录的各个部分链接在一起。这与早期按 “原样” 存储业务记录的记录保存系统(粘土片、理货筹码、纸张等)形成了强烈对比。规范化表示方式使业务纪录更难以理解,拆分和重组业务记录带来了更多的成本。

非规范化过程

本节介绍了非规范化成为常规实践的情况。数据仓库的数据库架构就是一个示例,像 Google BigTable [‎‎47] 和 HBase [‎‎49] 等新的可扩展的数据存储又是另一个示例。

规范化有两个固有的缺点。首先,在规范化的数据库架构中,复杂的业务记录往往会带来大量的关系表,这使得数据表示难以理解。因此,编写查询可能要求许多联接,变得越来越复杂 [‎‎46]。其次,潜在的大量联接会降低数据检索的性能。将规范化的表非规范化,或直接使用非规范化的设计,这两种方法可以解决这些问题。

数据仓库中的非规范化

在 20 世纪 80 年代和 90 年代,由于计算和存储设备的容量增加,而成本在不断降低,企业能够负担得起在数据仓库中对更大量的历史业务数据(如销售记录)进行积累和分析。为了获得对公司经营业绩的深入了解,业务人员所使用的这些仓库需要对直观表示的数据运行复杂的查询。人们很快发现,“在数据仓库中使用规范化建模完全违背了数据仓库的目的(即直观、高性能的数据检索)” [‎‎26]。

因此,非规范化的星型架构成为数据仓库中最流行的数据库架构。由于数据仓库通常会定期添加新的数据,而不是执行事务更新,所以非规范化简化了架构,提高了查询性能,同时具有较小的更新异常风险。

星型架构至少有一个事实表(如包含销售记录的 “每日销售”),和几个维度表(如 “商店”、“产品”、“日期” 和 “顾客”)。每个维度表和事实表之间是一到多的关系。每个事实表行包含了​​若干标准,即 “数量” 或 “价格” 等数字列,以及所有维度表的外键(用于表明哪个产品在哪个商店于哪个日期出售给哪位顾客)。这是一个直观的数据业务视图,并有利于根据相关的业务维度分析(销售)事实。

维度表是高度非规范化的。例如,“产品” 表可能有诸如 “品牌” 和 “类别” 这样的列,在这些列中,相同的字符串值可能会重复出现在多个产品记录中。规范化将使用 INTEGER (整型)值作为品牌和类别的键,再加上每个品牌类别的名称只出现一次的不同的表。应该避免维度表的这种规范化,因为它会导致更难理解且引入更多联接的雪花型架构。

数据仓库中星型架构的成功,导致人们普遍认为非规范化有利于 OLAP 和决策支持数据库。例如,Oracle 对数据仓库和 OLAP 数据库的建议包括 “大规模非规范化” 和 “广泛的冗余” [‎‎27]。Oracle 11g 的测试表明,多维查询在非规范化数据库架构上的运行速度可以比在规范化数据库架构上快 10 倍到 1000 倍 [‎‎28]。其他的研究也在理论上利用关系代数和查询树解释了非规范化的性能优势 [‎‎29]。

尽管非规范化在决策支持数据库取得了成功,但规范化通常适合于更新密集型 OLTP 应用程序。不过,在 21 世纪,随着越来越多应用程序需要保存所有数据库行的完整历史,OLTP 应用程序对规范化数据库架构的要求正在发生改变。因此,许多应用程序只执行插入新版本的行,而不执行更新现有的行 [45],这降低了非规范化架构中的更新异常风险,并减少对规范化的需求。

在 Google 的 BigTable、HBase 和其他系统中的非规范化

Google 的 BigTable 是一个并行的无共享数据库系统,它是作为一个稀疏式、分布式、多维、有序的地图 [‎‎47] 来实现的。BigTable 旨在实现大量数据(PB 级)的可扩展性,并在数百或数千台计算机上进行分发。在地图的每个条目上,BigTable 将由行键、列键和时间戳组成的三元组映射为一个值。此外,会将列键划分为列族,形成访问控制和压缩的基本单元。

为 BigTable 进行数据库和应用程序设计的主要原则之一是非规范化和数据复制 [‎‎48],这完全背离了传统关系数据库理论。其目的是优化数据库,实现高效和可伸缩的读访问。使用非规范化通常是为了让单一的读操作可以检索属于业务逻辑记录的所有字段。

BigTable 中,非规范化的代价是更加复杂和更低效的更新,因为可能必须以编程方式更新相同值的多个副本。接受这种牺牲是为了使表现出很高的读取/更新比率的应用程序获得高可扩展性。此外,BigTable 中的时间戳字段用于实现版本控制(即一个顾客地址的多个副本或一个产品说明的多个副本),以反映特定时间点的世界状态。

想像一下这样一个数据库,它存储客户和订单,它们之间是一对多的逻辑关系。关系型数据库规范化要求至少有两个表格,客户和订单各用一个表格,而典型的 BigTable 设计将在每个订单中重复客户信息。这代表了每个特定订单中的客户信息状态。例如,客户可能会也可能不会在每个订单中使用相同的地址。在此时,非规范化表示方式类似于实际采购订单的形式,也就是原始业务纪录。

类似于 BigTable 的其他实施,包括 HBase 和 Cassandra,也依赖于非规范化的数据库设计方法 [‎‎49]。同样,其他的研究表明,非规范化对于构建可伸缩的 Web 应用程序来说是一个成功的技术 [‎‎50]。

数据仓库由业务用户访问,所以它所存储的数据需要像业务记录的原始结构一样直观,这是通过非规范化实现的。非规范化还减少了评估业务记录所需要的关系联接数量,从而提高了性能。类似地,在 BigTable 和 HBase 等新的数据存储中,可以使用非规范化来提供简单的、可扩展的数据访问。

Web 的影响

从 20 世纪 90 年代中期开始,在业务记录数字化的同时,Web 也取得了商业上的成功。本节要介绍的是使业务记录的表示方式在 21 世纪初发生了重大变化的一些关键 Web 技术。

在 1989 年,随着更多科研、学术、政府和商业机构能够访问 Internet 基础架构,许多基于 Internet 的项目都进入了开发阶段。这些项目包括 HTML (超文本标记语言) [‎‎31]、 HTTP (超文本传输协议) [‎‎32] 和 URL (统一资源定位符) [‎‎33] 的发明,该项目导致了 World Wide Web (万维网) [‎‎34] 的创建。HTTP 定义了一个协议,通过一个统一寻址架构 (URL) 对 HTML 文件进行寻址,从而在 Internet 上检索和修改 HTML 文件。人们还构建了许多通用的查看器(浏览器 [‎‎35])来访问和浏览文件,并在 21 世纪的许多设备上使用它们。

科研机构是使用 Web 雏形共享科学文档的第一批用户。至 1995 年,商业界发现了 Web。由于许多消费者开始从他们的工作场所和家里访问 Internet,出现了一个将现有业务系统放到 Web 上的竞赛:创建一个 Web 站点,对存储在关系数据库中的数据提供访问,使消费者可以跟踪包裹,或者订购服务和商品。在过去,这些活动一直是由人工通过电话或信件来实现的。在开发出一些基础架构之后,人们使用它们来提供关系数据库的 Web 访问,并将其内容转换为无处不在的 HTML,而使用 HTML 作为其用户界面的应用程序也被创建出来 [‎‎36]。

HTML 取得了巨大的成功。1997 年的 4.0 版本的标准通用标记语言 (SGML) [‎‎38] 文档定义中对其进行了描述。SGML 起源于 IBM 在 20 世纪 60 年代的 Generalized Markup Language (通用标记语言),它是一个定义标记的 ISO 标准。SGML 的简化版本称为可扩展标记语言 (XML) [‎‎37],于 1998 年推出,与 HTML 所需要的完整 SGML 解析器相比,XML 简化了解析器的实现。关于在 XML 中的简化,举个例子,在 XML 中所有开始标记都必须有结束标记,而 SGML 则没有此类要求。

XML 的引入鼓励了许多超出 HTML 范围的词汇的创造,这些词汇用于表示任意数据结构。在 20 世纪 90 年代末,受到 Web 的刺激,人们以数字形式创建现实世界中的业务记录,将这作为一种输入输出介质,XML 成为以非规范化格式来表示业务记录的自然选择,就像纸质表格或石碑是非规范化的业务记录一样。免费的开源 XML 软件均衍生自 SGML 处理器,或者创建可以解析结构正确的 XML 的全新处理器,消除了自定义解析器的需要。

更多规范被引入来支持 XML,例如,使机构和联盟能够准确指定在特定业务记录中可接受的内容的 XML 架构。验证解析器的使用变得非常广泛。名称空间使一个业务记录能够包含由不同的组拥有其定义的数据。名称空间使机构可以重用、分区或扩展业务记录结构。数字签名可以被应用到 XML,以确保数字签名没有被篡改,这与在羊皮纸和纸上面使用的签名和盖章类似。

引入的规范描述了 XML 记录应如何传输,包括 WSDL、SOAP、RSS 和 Atom。它们使人们有可能围绕业务记录交换构建通用框架,如提要技术和面向服务架构 (SOA)。

为其行业定义 XML 中的业务记录标准的联盟数量有所增加。企业开始使用标准化的 XML 结构,而不是定义它们自己的 XML 业务记录。这方面的示例包括财务产品标示语言 (FpML) [‎‎52]、财务信息交换协议 (FIXML) [‎‎54]、EML(选举标示语言) [‎‎55]、HL7(健康水平 7)[‎‎56]、HR-XML(人力资源 XML)[‎‎57]、OTA(开放旅游联盟)[‎‎58] 和开放应用组集成规范 (OAGIS) [‎‎53]。诸如 IS20022 通用金融行业消息方案 [‎59] 之类的结构用于银行,UBL(通用业务语言)[‎‎60] 是强制性的,具体使用取决于相应的规范,在世界各地可能各不相同。在许多行业,首先要求能够直接存储和操作业务记录,因为在使用计算机之前的年代里,人们使用便签和纸张来记录信息。不过,规范化 (XML) 业务记录以存储它们的实践仍在继续。

在 21 世纪早期,许多业务记录都是使用 XML 创建和表示的。使用 XML 的业务记录是通过文件传输、HTTP、Web 2.0 和 Web 服务在各个体系之间进行交换的。它们代表双方或多方之间的业务对象或协定。通常假定处理 XML 是无效的。因此,许多架构师继续设计一些系统,将业务记录转换成为非规范化的关系表,或进行反向转换,就像以前所做的转换一样:在 1995 年,是在 HTML 和关系数据之间进行转换,而在 1980 年,则是通过扫描仪和人工输入在纸质记录和关系数据之间进行转换。

结束语

在 20 世纪中期推出商业计算之前,人们一直采用与创建商业记录相同的原始方式来存储和处理这些记录。这方面的示例包括石碑、理货筹码和纸张记录形式。随着计算系统的引入,人们设计出了数据规范化来组织业务记录,这样就可以将每个数据项都存储一次,从而保护存储并避免出现更新异常。规范化开发于 20 世纪 70 年代,当时开发规范化是出于竞争原因。那时磁盘空间稀缺而又昂贵,业务记录也不像现在这样复杂,并且只有最新的信息才有可能进行存储。因此,在将业务记录转换为计算机中的规范化表示形式或者进行反向转换时,为此而做的工作通常能够被人们所接受。

20 世纪 90 年代,随着数据仓库和业务智能的出现,规范化的缺点受到了人们的关注。规范化的数据库方案是业务记录的一种非自然的表示形式,业务用户非常难以理解它,它对于规划和处理分析型业务查询是无效的。因此,人们引入了取消规范化的概念,可以将该缺陷削减至某种程度。

在 21 世纪,IT 世界不断发生着变化。每 MB 的数字存储空间的成本也在急剧下降。由于存储密度和压缩技术方面的改进,规范化已经不再是节省空间所必需的。类似地,审计和合规法规目前要求许多应用程序保留其数据对象的历史记录。结果,插入新的、不可变的数据对象版本通常比更新现有数据更常见,这样做减少了更新异常风险。因此,数据规范化的需求已经不像 20 世纪 70 年代那样普遍适用。

此外,Web、Web Services 和 Web 2.0 技术取得了成功,它们可以确保业务记录是以数字形式(主要是 XML)创建的。客户端软件已经开始利用 XML 及其派生物,而涉及数据库的服务器端软件通常仍然明确要求对针对设计、构建和演化的定制,为了完成规范化所需的数据转换。需要数据规范化的原因之一是,在过去的 30 多年里,数据规范化一直被认为是一种数据库设计方法,并且目前仍然被认为是系统设计的一个组成部分。然而,因为业务记录现在是数字的,更加复杂,并在不断演化,所以是时候重新仔细思考规范化的使用。

本系列的第二部分将讨论 XML 和其他替代数据表示方式,并研究它们如何减轻常见的规范化问题。

引用

1. 苏美尔: http://en.wikipedia.org/wiki/Sumer

2. 银行的历史: http://en.wikipedia.org/wiki/History_of_banking

3. 汉穆拉比法典:http://en.wikipedia.org/wiki/Code_of_Hammurabi

4. 中世纪的贸易和商业:http://www.camelotintl.com/village/trade.html

5. 理货筹码: http://en.wikipedia.org/wiki/Tally_stick

6. 纸的历史:http://en.wikipedia.org/wiki/History_of_paper

7. ERMA - 会计的计算机处理系统的电子记录方法: http://inventors.about.com/library/inventors/bl_ERMA_Computer.htm

8. 穿孔卡:http://en.wikipedia.org/wiki/Punched_card

9. 磁带:http://en.wikipedia.org/wiki/Magnetic_storage

10. 磁盘存储:http://en.wikipedia.org/wiki/Disk_storage

11. 批处理:http://en.wikipedia.org/wiki/Batch_processing

12. 数据库系统:http://en.wikipedia.org/wiki/Database_management_system

13. ISAM Direct: http://en.wikipedia.org/wiki/ISAM

14. Olle T.W.: "The Codasyl Approach to Data Base Management". Wiley, 1978. ISBN 0-471-99579-7。

15. 层次模型:http://en.wikipedia.org/wiki/Database_model#Hierarchical_model, http://www.ibm.com/software/data/ims/

16. Codd, E.F. "Further Normalization of the Data Base Relational Model." IBM Research Report RJ909, 1971。另见 Data Base Systems: Courant Computer Science Symposia Series 6, Prentice-Hall, 1972。

17. Kent, W.:"A Simple Guide to Five Normal Forms in Relational Database Theory", Communications of the ACM, Vol. 26, pp. 120–125, 1983

18. Date, C. J.: "An Introduction to Database Systems", 8th Edition. Addison-Wesley Longman, ISBN 0-321-19784-4, 1999。

19. IBM 3330 磁盘存储设备:http://www.ibm.com/ibm/history/exhibits/storage/storage_3330.html

20. 3380 磁盘:http://www.ibm.com/ibm/history/exhibits/storage/storage_3380.html

21. 衡量价值:http://www.measuringworth.com/ppowerus/

22. 国际平均工资收入数据库:http://www.worldsalaries.org/usa.shtml

23. 电子文档管理系统: http://en.wikipedia.org/wiki/Document_management_system

24. 企业内容管理:http://en.wikipedia.org/wiki/Enterprise_content_management

25. 缩微胶片: http://en.wikipedia.org/wiki/Microform

26. Kimball, Ralph: The Data Warehouse Toolkit, 2nd Ed.. Wiley Computer Publishing (2002)。

27. Burleson, Donald: "Developing Effective Oracle Data Warehouse and OLAP Applications", http://www.dba-oracle.com/art_dw1.htm, 1996

28. Zaker, M. et al.: "Hierarchical Denormalizing: A Possibility to Optimize the Data Warehouse Design", International Journal Of Computers, Issue 1, Volume 3, pp. 143-150, 2009。

29. Sanders, G. 和 Shin, S.:"Denormalization Effects on Performance of RDBMs", 34th Hawaii International Conference on System Sciences, HICSS 2001。

30. Codd, E.F. "A Relational Model of Data for Large Shared Data Banks", Communications of the ACM 13 (6): 377–387, 1970。

31. 超文本标记语言:http://en.wikipedia.org/wiki/HTML

32. 超文本传输协议: http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol

33. 统一资源定位符:http://en.wikipedia.org/wiki/Uniform_Resource_Identifier

34. 万维网:http://en.wikipedia.org/wiki/World_Wide_Web

35. Web 浏览器:http://en.wikipedia.org/wiki/Web_browser

36. 万维网的时间表:http://www.w3.org/History.html

37. 可扩展标记语言:http://www.w3.org/XML/

38. SGML 和 XML 的区别:http://www.w3.org/TR/NOTE-sgml-xml-971215

39. Murthy, R. et al.: "Towards an enterprise XML architecture", SIGMOD 2005。

40. Nicola, M., Gonzalez, A.: "Taming a Terabyte of XML Data", IBM Data Management magazine, Vol. 14, Issue 1, 2009。

41. Nicola, M., van-der-Linden, B.: "Native Support XML in DB2 Universal Database", 31st International Conference on Very Large Databases, VLDB 2005。

42. Nicola, M.: "Lessons Learned from DB2 pureXML Applications: A Practitioner’s Perspective", 7th International XML Database Symposium, XSYM 2010

43. Rys, M.: "XML and Relational Database Management Systems: Inside Microsoft SQL Server", SIGMOD 2005

44. Holstege, M.: "Big, Fast, XQuery: Enabling Content Applications", IEEE Data Engineering Bulletin, Vol. 31 No. 4, 2008

45. Helland, Pat: "Accountants Don't Use Erasers", 2007 年 6 月

46. Helland, Pat: "Normalization Is for Sissies", 2007 年 6 月

47. Chang et al.: "Bigtable: A Distributed Storage System for Structured Data", 7th Symposium on Operating Systems Design and Implementation, OSDI 2006。

48. "How I Learned to Stop Worrying and Love Using a Lot of Disk Space to Scale"

49. Liu, Qingyan: "HBase Schema Design Case studies", http://www.slideshare.net/hmisty/20090713-hbase-schema-design-case-studies, 2009

50. Wei, Z. et al.: "Service-Oriented Data Denormalization for Scalable Web Applications", International World-Wide Web Conference, WWW 2008。

51. Carey, M. J. et al.: "EXRT: Towards a Simple Benchmark for XML Readiness Testing", 2nd Conference of the Transaction Processing Council, TPCTC 2010。

52. FpML (金融产品标记语言): http://www.fpml.org/

53. Open Applications Group Integration Specification (OAGIS,开放应用程序组集成规范): http://www.oagi.org/

54. The Financial Information eXchange Protocol, FIXML 4.4 Schema Specification 20040109, Revision1 2006-10-06, http://www.fixprotocol.org/specifications/fix4.4fixml

55. OASIS 的 EML (选举标记语言)规范:http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl

56. HL7 (Health Level 7) 规范:http://www.hl7.org/

57. 人力资源 XML (HR-XML) 规范:http://www.hr-xml.org/

58. 开放旅游联盟规范: http://www.opentravel.org/

59. ISO 20022 通用金融业信息架构:http://www.iso20022.org/

60. OASIS 的 UBL (通用商业语言): http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl

61. 链接数据参考 - 链接数据: http://en.wikipedia.org/wiki/Linked_Data

62. RDF 参考 – RDF 入门: http://www.w3.org/TR/rdf-primer/

63. How Best Buy is using the Semantic Web: http://www.readwriteweb.com/archives/how_best_buy_is_using_the_semantic_web.php

64. JSON: http://www.json.org/

参考资料

学习

获得产品和技术

讨论

  • 加入 developerWorks 中文社区。查看开发人员推动的博客、论坛、组和维基,并与其他 developerWorks 用户交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Information Management
ArticleID=800406
ArticleTitle=数据规范化反思,第 1 部分: 业务记录的历史
publish-date=03052012