数据规范化反思,第 2 部分: 21 世纪的业务记录

关于计算机系统中的业务记录的研究

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

本系列分为两部分,第一部分对记录保存进行了历史回顾,并探讨了与数据规范化有关的问题,例如,将不断发展的业务记录映射为规范化格式的难度。由于 Internet 导致了数字格式(如 XML)的业务记录的广泛创建,在计算机系统中以其原始格式存储记录已成为可能。

本系列第二部分将讨论可以克服规范化问题或引入架构灵活性的其他数据表示方式,如 XML、JSON 和 RDF。在 21 世纪,数字化的业务记录往往从使用 XML 创建业务记录开始。本文对 XML 与规范化关系结构进行比较,并说明 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 公司负责数据仓库性能方面的工作。他从德国的亚琛科技大学获得计算机科学博士学位。



2012 年 3 月 12 日

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

简介

本系列分为两部分,第一部分讨论 21 世纪前的记录保存,以及关系数据库和 Web 的影响。引入计算机系统之前,业务记录是按 “原样” 以其原始非规范化格式进行创建和保存的。这样的例子包括有石碑、理货筹码或纸质表格。引入计算系统之后,数据规范化亦随之制定,以便能够将业务记录转换成另一种表示方式,从而节省空间,避免数据库中出现更新异常。然而,规范化表示方式与原始方式有很大差异,并且难以理解。

本系列的第二个部分将探讨数据格式和业务记录在 21 世纪的发展趋势。本文从案例研究开始,强调在没有规范化的情况下实现数字化业务记录的好处,例如,性能更好,应用开发和维护成本更低。本文还将讨论 JSON 和 RDF 等其他新兴的数据表示方式,重点讨论它们在相关使用场景中的利弊。

关系数据表示和 XML 数据表示:比较

如今,许多系统和应用程序将业务记录创建并表示为 XML 文档。例如,每个订单、每笔财务交易、每张纳税申报表、每个保险索赔,等等,每个业务记录往往是一个单独的 XML 文档。主要的原因是,XML 是可扩展的、灵活的、自描述的并且适用于结构化、非结构化和半结构化信息的组合。要表示复杂的记录,可以根据需要扩展数据表示形式,并在应用程序之间 (A2A) 或组织之间 (B2B) 交换业务记录,上述这些属性使得这一切都很容易。因此,XML 已经成为 Web 服务和面向服务的架构 (SOA) 首选的数据格式。

为了应对这一趋势,主要的数据库厂商已在其产品中添加了 XML 功能 [1] [3] [5],并且已出现了几个只支持 XML 的数据库 [6]。此类产品可以实现 XML 的存储、索引、查询,并且支持更新 XML 的 ACID 事务、可恢复性、可扩展性、高可用性等许多与关系数据相同的属性。这些数据库技术的进步使人们有可能以其原始格式 (XML) 来存储和管理业务记录。本节在(非)规范化、冗余性和性能方面对 XML 与关系数据进行对比。

示例

由于 XML 是一个层次型数据格式,一个 XML 文档可以代表任意数量的一到多关系,无需将这些关系规范化为一组不相交的对象。

想像一个用于描述客户的业务记录,每个客户可以有多个地址、多个电话号码、多个电子邮件地址、多个中间名、多个投资账户。此外,每个客户的帐户可以有多个位置(财产),每个地址可以有多个 “街” 条目,等等。在规范化的关系架构中,这里面每个一到多关系都需要一个额外的表,如图 1 所示。因此,存储一个业务记录就需要在多个表中执行多个 SQL INSERT 语句,在本例中,在 12 个表中使用了多达 12 个的 INSERT 语句。

图 1. 规范化的关系架构示例
此图显示了一个规范化的客户记录

同样,当应用程序检索单个客户记录时,它需要对所有 12 个表发出 SELECT 语句。这是一种低效的过程,因为需要对数据库进行 12 次或以上的独立 API 调用。每个调用都会产生网络流量,访问一个数据库表,并可能带来表及其索引的物理 I/O。请注意,联接 12 个表的单个查询通常会引起更严重的问题。例如,如果一个客户有 3 个账户,一共 7 个位置(如表 1 至表 3 所示),跨这三个表的一个联接将返回 7 行结果,如表 4 所示。在这个结果集中,来自客户表中的选定值被重复 7 次,并且对他们的每一个位置都重复一次每个帐户的值。这样的冗余会迅速增加结果集的大小,因此,“客户端 - 服务器” 通信的延迟会使性能下降。如果将更多的表添加到联接中,结果集将会迅速增大并使问题更加严重。

表 1 至表 3 显示了 Customer(客户)、Account(帐户)和 Position(位置)数据的规范化关系架构。

表 1. Customer 表
CidFirstNameLastNameDateOfBirthNationality
12345JohnDoe1965-09-27German
表 2. Account 表
CidAccNoCurrencyBalance
12345985739476Euro120,000
12345985710938Euro2786.23
12345985808142USD523,891
表 3. Positions 表
AccNoSymbolShares
985739476IBM1,200
985739476ORCL2,500
985739476VFINX550
985710938SBTYA12,000
985710938VIVAX75
985808142DWCT1,128
985808142PMCOA8,461
表 4. 例如,在联接查询的结果集中的非规范化数据
CidFirstNameLastNameDateOfBirthNationalityAccNoCurrencyAccBalanceSymbolShares
12345JohnDoe1965-09-27German985739476Euro120,000IBM1,200
12345JohnDoe1965-09-27German985739476Euro120,000ORCL2,500
12345JohnDoe1965-09-27German985739476Euro120,000VFINX550
12345JohnDoe1965-09-27German985710938Euro2786.23SBTYA12,000
12345JohnDoe1965-09-27German985710938Euro2786.23VIVAX75
12345JohnDoe1965-09-27German985808142USD523,891DWCT1,128
12345JohnDoe1965-09-27German985808142USD523,891PMCOA8,461

表 4 也说明了数据库架构的非规范化如何引入数据冗余。相比之下,清单 1 显示了相同逻辑业务记录的一种 XML 表示方式。规范化的关系架构将客户信息分散到多个表中,而 XML 树结构则可以在单一文件中表示相同的一对多关系。同时,该文件并不包含任何冗余,因为不需要为每个子节点(如 “Account” )重复一次父节点(如 “Customer”)。所以 XML 可以在单一的非规范化文件中表示一个业务记录,而不会产生冗余。因此,可以用单个 SQL 语句插入或检索业务记录,从而减少数据库 API 调用次数,降低应用程序的复杂性、CPU 成本以及网络流量。已在多个商业数据库系统观察和测量到这些优势,我们会在下一节中进行讨论。

清单 1. Customer、Account 和 Position 数据的 XML 表示
                <Customer Cid="12345">
                    <FirstName>John</FirstName>
                    <LastName>Doe</LastName>
                    <DateOfBirth>1965-09-27</DateOfBirth>
                    <Nationality>German</Nationality>
                    <Accounts>
                        <Account AccNo="985739476">
                            <Currency>Euro</Currency>
                            <Balance>120000</Balance>
                            <Positions>
                                <Stock Sym="IBM" Shares="1,200"/>
                                ...
                            </Positions>
                        </Account>
                        <Account AccNo="985710938">
                            <Currency>Euro</Currency>
                            <Balance>2786.23</Balance>
                            <Positions> ... </Positions>
                        </Account>
                        <Account AccNo="985808142">
                            <Currency>USD</Currency>
                            <Balance>523891</Balance>
                            <Positions> ... </Positions>
                        </Account>
                    </Accounts>
                </Customer>

XML 和关系型在 OLTP 系统中的性能比较

将业务记录作为一个非标准化 XML 文件(而不是规范化的关系行)执行插入和检索的好处正受到数据库从业者的关注。一个大型的全球物流企业已经对这个价值主张进行了测试。该企业的一个 OLTP 系统使用规范化的关系架构来表示特定的业务记录,该规范化关系架构由 12 个表组成。为了检索一个业务记录,应用程序需要发出 15 个 SQL 语句。大多数业务记录由 15 行表示,但有一部分业务记录包含数百行。为了进行比较,他们选择了 250,000 个业务记录,并把这些业务记录转换成 XML 格式,每个业务记录一个文件。大多数文件的大小是 1KB 至 2KB,但也有一些高达 500KB。

测试场景在配有 32GB 内存的 8 核心 AMD Opteron 服务器上使用附带 Linux RHEL4.6 的 DB2 9.5 Fix Pack 4。多达 7 个客户端计算机被用来模拟不断增加的并发数据库访问用户。每个客户端是一台 IBM xSeries 345(2 核)计算机。这 12 个关系表中的每一个表都有适当的索引。为了进行比较,XML 文件存储在一个表的一个 XML 列中,并且只在记录的 ID 属性上有一个 XML 索引。在关系型的测试中,每一个模拟的并发用户都选择一个随机的记录 ID,每个 ID 发出一个有 15 个 SQL 查询的事务来检索该业务记录的所有信息。不考虑所使用的时间。在 XML 的测试中,每个并发用户都选择一个随机的记录 ID,并发出一个 SQL/XML 查询,在 XMLEXISTS 谓词中使用 XPath 表达式来检索 XML 文件。

结果如图 2 所示。XML 解决方案的吞吐量比规范化关系架构平均高 55%。在关系型测试中,84 个并发用户每秒执行约 3800 个事务时,用于测试的系统的 CPU 能力被耗尽。在 XML 解决方案的测试中,同一个系统支持多达 150 个并发用户和每秒近 6000 个事务。同时,在客户端计算机上的 CPU 利用率指标上,XML 解决方案大大低于关系型解决方案。

图 2. 检索性能:非规范化的 XML 与规范化的关系数据比较
该图中的图表,显示出 XML 列具有更高性能

对于该物流公司,非规范化的 XML 解决方案的好处远远不只是更高的性能和更低的 CPU 消耗。例如,每个 XML 文件都可以立刻供客户端应用程序使用,而检索的关系行则要求业务纪录的构建,图 2 的测量值中并未包括这项额外成本。此外,XML 解决方案的数据库架构更简单,并且当记录格式随时间推移而演变时更易于维护。业务记录在数据库和应用程序 (XML) 中的表示方式相同,从而简化了应用程序的开发。报告中亦包括基于 XML 的表单处理、事件记录和订单处理所带来的好处 [‎‎4]。

与表示相同业务记录的规范化关系表的等效访问相比,XML 访问使用较少的 CPU。与在 XML 中传输业务记录本身相比,用关系联接重构业务记录将使得在数据库和客户端之间传输的数据更多。此外,XML 更容易理解,因为它更接近(即使不是完全相同)于现实世界的业务记录。一个单独的逻辑数据模型已不再需要。现实世界的业务记录和储存在计算机内的数据之间的映射并不是必需的。

语义 Web 和 RDF(资源定义框架)

另一个趋势是 Linked Data(链接数据)和 Semantic Web(语义 Web)的出现。更具体地说,Linked Data(链接数据)已被定义为 “在使用 URI 和 RDF 的语义 Web 上陈列、共享和连接数据、信息和知识块的建议最佳实践”。利用 RDF,资源以 “主-谓-宾” 表达式的语句形式来表示。这些表达式被称为三元组 [‎8],如清单 2 和表 5、表 6、表 7 所示。

清单 2. XML
<DEPARTMENT deptid="15" deptname="Sales">
   <EMPLOYEE>
     <EMPNO>10</EMPNO>
     <FIRSTNAME>CHRISTINE>/FIRSTNAME>
     <LASTNAME>SMITH</LASTNAME>
     <PHONE>408-463-4963</PHONE>
     <SALARY>52750.00</SALARY>
   </EMPLOYEE>
   <EMPLOYEE>
   <EMPNO>27</EMPNO>
   <FIRSTNAME>MICHAEL>/FIRSTNAME>
   <LASTNAME>THOMPSON</LASTNAME>
   <PHONE>408-463-1234</PHONE>
   <SALARY>41250.00</SALARY>
   </EMPLOYEE>
</DEPARTMENT>
表 5. 链接数据(RDF 表)
deptidhasdepname
deptidhasdep15
Salesisadeptname
Saleshasdepid15
emphasdeptid
emphasempno27
emphasempno10
27isanempnofordepid15
10isanempnofordepid15
表 6. 规范化的关系数据 (a)
DEPTIDDEPTNAME
15Sales
表 7. 规范化的关系数据 (b)
DEPTIDEMPNOFIRSTNAMELASTNAMEPHONESALARY
1527MICHAELJONES408-461-123441250
1510CHRISTINESMITH408-040-805152780

拆分成三元组的数据规范化是 Semantic Web(语义 Web)的一个重要组成部分,用以构建 RDF 存储,从中可以得到强大的集成。通过将信息分解成最小的元素(三元组),可以将数据表示为图表,其中主语和宾语作为节点,而谓词则用作连接弧 (linking arc)。推理软件(推理工具)可以分析图表并应用规则来推导出新的语句。例如,由于部门中包含一些员工,而人力资源部是一个部门,那么可以推导出一个新的语句,人力资源部有员工。

链接数据的链接通常只连接最新信息,关系表中的主键和外键亦是如此。例如,通过链接或通过导航关系键构建的订单,其审计将选择当前客户地址,而不是选择下订单时的客户地址。在业务系统中,由于审计与合规性的原因,在发生重要事件(如接到订单或发出的银行对帐单)时,往往必须保存相关业务信息的快照。保存快照的目的是,在审计或查询时,不需要依靠在稍后日期所发生的导航来重构业务记录。有时会对快照进行签署,以提供证据,证明业务记录自其创建以来未被篡改。

极端形式的规范化的 RDF 与规范化的关系数据类似,版本控制的处理以及历史与审计的管理都相当困难。RDF 与关系数据的差异在于,它不依赖于一个固定架构。如果资源有新的属性,只需添加更多语句(三元组)就能很容易地表示这些新属性。但是,三元组的查询也有可能比传统的关系架构查询更难。

Linked Data(链接数据)和 Semantic Web(语义 Web)的机制都很强大,并且可以整合看似无关的系统。例如,整合酒店和机票预订、订单处理或利用社交网络信息进行保险续约。用语义注释(三元组)充实(以 XML 表示的)业务记录,这提供了传统业务记录与 Linked Data(链接数据)和 Semantic Web(语义 Web)结构的融合方式。美国零售商 Best Buy 就是一个现实世界的示例,Best Buy 利用 RDFa(RDF 注释)诠释其描述产品的 XHTML 页面,可以用程序化程度更高的方式来处理 RDFa,例如,通过搜索引擎和分类工具 [‎‎9]。

将语义注释融入关系数据库更困难,因为并没有适当的机制在不改变关系数据库架构的条件下就能充实关系数据,相比之下,在以 XML 表示的业务记录中,注释的应用更直接简单。

JSON

JSON (JavaScript Object Notation) 以 JavaScript Programming Language(JavaScript 编程语言)的一个子集为基础,并已成为向 JavaScript 客户端呈现信息的流行语言 [‎‎‎10]。事实上,许多 REST 和 Web API 都提供 XML 和 JSON 的变体。可以将 JSON 看作是一个轻量级的数据交换格式,适用于使用 JavaScript 构建人类用户界面。对于人类而言,它易于读写,对于 JavaScript 而言,它易于解析和生成。表 8 显示了一个数据示例,并对 JSON 和 XML 表示法进行了比较。

表 8. JSON 与 XML 的比较
JSONXML
 {
    "city": "Armonk",
    "state": "NY",
    "population": 4080
 }
<root type="object">
   <city type="string">Armonk</city>
   <state type="string">NY</state>
   <population type="number">4080</population>
</root>

JSON 非常适用于即时格式化查询结果,使 JavaScript 客户端的处理更简单。因此,JSON 对于 Web 应用程序非常流行。然而,JSON 并没有名称空间,所以即使有可用的约束,它们也不能轻易地被共享、扩展或混合。JSON 的支持规范(如架构或转换语言)并不存在,或者尚未达到与 XML 相同水平的成熟度。虽然在数据规范化方面,JSON 与 XML 有一些共同的优势,但其成熟水平尚未与 XML 相当,亦未达到关系数据和链接数据的水平,如表 9 所示。

表 9. 关系数据、XML、JSON 和链接数据的比较
关系数据XMLJSON链接的数据
元数据数据定义语言 (ISO)XML 架构 XSD (W3C),
名称空间 (W3C)
JSON 架构 (IETF)RDFS(RDF 架构),
Ontology(W3C 及其他地方)
约束表定义的完整性约束 (ISO)Schematron (ISO),
Relax-NG (OASIS)
-
触发器关系型触发器--RIF (W3C)
数据交换的序列化 SQL 标准 (ISO) 定义了一个 XML 序列化,但它并未得到广泛使用 – 尚未有商定的 JSON 序列化。存在 RDF 序列化XML 在数据交换中是广泛使用的语法 (W3C)JSON 是一个序列化的格式,也存在用 XML 表示的 JSONXML, Turtle
表示法不是关系模型的组成部分针对 XML 架构和 XML 数据定义的多种注释-RDFa (W3C) 可以用于注释 XML
查询与 CRUD 语言数据操纵语言 (Data Manipulation Language, DML), SQL, SQL/XML (ISO)XPath, XQuery (W3C) 及其他 CRUD 语言JAQL, JSONiqSPARQL (W3C)
Query 与 CRUD API多种不同的编程语言,例如 JDBC 和 ODBC多种,包括部分关系型 API 和特定的 API,例如 XQJ-SPARQL Graph Store HTTP Protocol – 适用于 CRUD (W3C)
集合表、视图、数据库 (ISO)XML 集合函数 (W3C)-RDF 图表 (W3C)
转换与其他语言SQL(表到表)XSLT(XML 至文本,包括 XML);XForms
SQL XMLTABLE(XML 到关系型)
JavaScript-

小结

在大多数商业项目中,数据规范化是从早期就开始关注的一个过程,它几乎总是阻止以原始形式(如 XML)进行业务记录存储。此外,经常假定使用 XML 业务记录是低效的。在本文中的性能比较表明,实际情况并非如此。事实上,从规范化的表中检索和重构业务记录的成本往往比本地存储和检索非规范化的 XML 文件的成本高。因此,在使用 XML 来表示业务记录的场景中,XML 应该也可视为相应的存储格式。以对象为中心的数据访问使用 XML 时的性能往往优于使用规范化关系表时的性能,并且它实现了较高的 XML 事务率 [2]。此外,XML 使应用程序可以实现敏捷的原型制造、开发和演变,因为不必设计和维护关系表与 XML 之间的映射。

Google Big Table 和 HBase 等新兴的存储系统也背离了规范化。它们主张强大的非规范化,并根据数据的访问方式进行数据存储。XML 数据库提出了相同的建议,业务记录最好以与典型访问模式匹配的粒度进行存储 [‎4]。

Linked Data(链接数据)、Semantic Web(语义 Web)和 JSON 是新兴的数据表示方式,但在用于系统间数据交换的业务系统中尚未普及。将数据规范化拆分为三元组(三元组是 Semantic Web 的重要组成部分),从而可以构建 RDF 存储,通过推理从中获得新的事实。利用 RDFa 等语义注释充实以 XML 表示的业务记录,这提供了传统业务记录与 Linked Data(链接数据)和 Semantic Web(语义 Web)的融合方式。

尽管有了这些进步,规范化仍未过时。规范化仍然很有用,例如,用于传统的关系事务处理系统,这些系统支持较高的更新率,很少需要重构原来的业务记录,并且不会执行新版本记录的插入,也不会执行传统版本的更新,如表 10 所示。

表 10. 规范化与非规范化存储的适用性比较
适用于非规范化数据表示,例如 XML适用于规范化或半非规范化数据表示
1“以对象为中心” 的数据访问:一起访问全部或大部分业务记录数据访问是面向集合或面向列的,例如,用于分析
2通过 Web 服务和 SOA 交换完整的业务记录不需要重组原始业务记录
3要求版本控制:用不可变版本的插入取代数据更新 只需要保留每个业务记录的最新状态
4需要支持架构演变架构成熟、稳定,并且不可能演变
5业务纪录的审计与合规性是关键审计/合规性要求是短期的、薄弱的或不存在

关系数据库系统、数据规范化、以及后来业务记录的 XML 表示方式,它们的巨大成功在当时都有令人信服的理由。在 21 世纪,按 “原样” 存储和操纵业务记录,这通常是有意义的。用现实世界打个比喻:人类获取、操纵、存储实际的东西,例如,衣服放在衣柜里,车放在车库中。针对主要访问类型以最适当的形式保存这些东西,也就是说,汽车和衣服在保存之前都没有先被拆解,如图 3 所示。

图 3. 一辆汽车的完整存储与 “规范化” 存储的比较
本图在左侧显示了一辆汽车,并在右侧显示了一辆被拆开的汽车。

结束语

这个由两部分组成的文章系列认为,数据规范化是存储完整的业务记录并提供敏捷数据管理解决方案的一个主要障碍。高效的 XML 数据库都是现成的 [‎7],但往往被忽视,因为在系统设计的早期步骤中已纳入规范化,消除了原始业务记录的所有痕迹。我们应仔细反思数据规范化。


引用

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

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

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

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

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

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

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

8. RDF 参考 - RDF 入门

9. Best Buy 如何使用 Semantic Web

10. 介绍 JSON

参考资料

学习

获得产品和技术

讨论

  • 加入 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=801534
ArticleTitle=数据规范化反思,第 2 部分: 21 世纪的业务记录
publish-date=03122012