IDC资讯中心
最近逛书店发现一本数据建模的好书——《数据建模：分析与设计的工具和技巧》(data modelers workbench：tools and techniques for analysis and design)，作者steve hoberman。粗读完一遍后，感觉这本书的确无愧于译者和国外专家们的盛赞：“这本书充满了对改进数据模型和设计有益的技术和技巧，并且它还极富阅读乐趣——一个了不起的结合！任何一个数据建模者都应该拥有一本steve hoberman的关于数据建模工具和技术的书。”
尽管我对自己所掌握的数据建模知识有一定的自负，读完该书后，还是获益良多。本着好书大家一起分享的想法，我把该书的每个章节的总结和技巧建议列出来，以方便手头暂时没有该书的朋友在数据建模时参考。该书所介绍的工具和模版可在作者的web站点下载，地址是：
www.wiley.com/compbooks/hoberman
第一章：使用趣闻、类比和演示文稿来阐明数据建模的概念
在一般的日常沟通中。我们可能会说出并听到许多故事、或者趣闻这些故事涉及的论题范围很大。有些例子是周末发生在我们自己身边的事情，或者是与我们的工作项目有关的经历。这些趣闻有助于加强我们和周围人们的关系，增进我们的愉悦情绪，而且对我们有教育作用。我们能够把由语言表达出来的东西形象化。有时，当故事结束时，给我们留下的是以前未曾想到的信息或更多的认识。在解释数据建模概念时，趣闻是极其有效的。原因有如下几个：
它们建立起持久的形象。
它们引人入胜、使人愉悦。
它们增经人们之间的关系。
它们减缓压力。
成功编造并讲述一个数据建模方面的趣闻有下面三个简单的步骤：
1)定义一个论题。要在心中保证，你讲述的这个趣闻有一个特定的目标或论题，也就是说，这个故事是为了解释一个数据建模的概念或术语。
2)选择你的故事。我们可以选择的故事类型多种多样。我们要考虑选择一个有趣并有益，而且能够明白无误地传达主题意图的简短的故事。
3)演练你的故事。一旦找到了合适的故事，你要好好演练一番，直到你自信它能够在两分钟的时间内充分表达你的论题。要避免讲述拖拖拉拉的故事。
数据模型类比
类比就是把两个或多个概念进行相互比较，以强调它们之间的相似或差异。类比是介绍外来事物或新鲜事物的一个很好的技巧，尤其是向非计算机专业的人士介绍计算机的专业知识时。hoberman在数据建模中最常见的几个类比如下（他用这些类比轻松的打动管理层给他涨了一倍的工资^_^）：
主体域模型是一个居高临下的视点。
数据模型是一个设计图。
企业模型是一个世界地图。
标准就是城市规划。
元数据仓储库是一个图书馆。
数据仓库是“心脏”。
第二章：元数据宾果游戏
简单来说，即通过宾果卡片游戏的方式，调动项目团队成员的积极性，来确定数据模型，并确定元数据的有效性。元数据宾果游戏强调“共赢”，如果运气好，游戏结束时每个人都能赢。
第三章：确保高质量的定义
本章集中讨论一个被称为“定义检查单”(definition checklist)的工具，它包含了确保定义的质量处于最高水平的准则。
第四章：数据建模者的项目计划
本章重点介绍确定数据建模阶段、任务、工具和时限的四个工具：
·数据建模阶段的工具：用来确定最高层次上的数据建模步骤。
·阶段—任务—工具：提取出“数据建模阶段”的各个阶段并把他们分解成数据建模任务。
·优先级三角形：你可以从以下三项中取两项极值：很高的质量、最短的时间与最低的成本，但你永远也别想三者兼得。
·可靠的估算工具：“主体域工作量时限”根据应用程序的类型，确定每个数据建模阶段应占整个项目的百分比。“任务工作量工具”提取在“阶段—任务—工具”中确定的每项任务，并列出它们应占整个数据建模工作产品的百分比。这两个工具的组合可使你向项目经理提供一份具有一定精确度的合理估算。
第五章：主体域分析
本章主要探讨五个关键的工具，这五个工具对数据建模工作的主体域分析阶段有帮组作用。它们应该按照下面的顺序被逐个完成：
1)主体域检查单：新应用程序中的主体域的完整列表，还有各个主体域的定义和同义词（或别名）。
2)主体域crud(create read update delete)矩阵：包含新应用程序和现有应用程序之间的主体域方面的差别和重复之处，确定应用程序的范围。
3)in-the-know模版：确定完成这个新应用程序的数据间模工作产品所需要的、被用作资源的人员和文档。
4)主体域家族树：包含每一个主体域的源应用程序和若干其他的关键信息，阐明主体域数据将来自哪里。
5)主体域力度矩阵：使用一个电子表格的格式，记录每一个度量和事实主体域的发布层次。
第六章：主体域建模
本章阐述三个队主体域信息进行建模的强大工具：
·“业务清理板”模型。
·“应用程序清理板”模型。
·“早期现实性检查”模型。
第七章：逻辑数据分析
本章关注四个逻辑数据分析工具，它们应该按照下面的次序被使用：
1)数据元素家族树：包含应用程序的数据元素的完整列表，以及每个数据元素的来源和变换信息，还有其他几个关键的数据元素元数据。
2)数据元素粒度矩阵：用一个电子表格的格式，来记录每个度量和事实的发布层次。
3)数据质量记录模板：展示每个数据元素的员数据和一些实际数据的对比。
4)数据质量确认模板：记录每个数据元素的元数据和一些实际数据的对比的结果。
第八章：规范化之旅和反向规范化生存指南（强烈推荐：是我目前所读过最好的关系型数据库的规范化技术文档）
规范化是一个剔除冗余并应用规则的过程，它的目的是为了更好的理解和表达存在于数据元素之间的依赖性和参与性。规范化包含6个层次，最高层是第五范式(5nf)。一般的技术文档上都认为达到3nf即可，steve hoberman给我们指明了更高的目标：5nf。graeme simsion写过一本名为《data modeling essentials》的书，在这本书中，他写道：“较高层次的范式常被从业者误解并因此而被忽视，或为了支持不可靠的建模时间而被引用。”但是，我们需要理解这些较高层次的规范化，因为它们体现了额外的规范化机会，并帮组我们进一步减少冗余信息、改进设计的灵活性。尽管余下的三个规范化层次有可能仅仅产生次数很少的变化，但它们仍然具有一些提高灵活性和效率的机会。下面是bcnf&4nf&5nf的定义(比国内教材上罗列的数学公式容易理解得多^_^)：
bcnf=3nf＋下面的规则：
每一个数据元素都完全依赖于键、整个键，而且除依赖于这个键以外，不依赖于任何其他数据元素。
4nf=3nf+下面的规则：
要把主键中拥有三个或更多外建数据元素、切割格外键之间不存在约束的那些实体分解成两个或更多个实体。
5nf=4nf+下面的规则：
把主键中拥有三个或更多的外键数据元素，且这些外键数据元素之间存在着约束的实体分解成为所有的约束都需要的多对多的关系。
当我们攀上5nf的顶峰后，再根据实际需求情况来进行“反向规范化”增加数据冗余，从而简化开发，提高查询速度。反向规范化是这样一个过程：在定义了一个可靠的、完全规范化了的数据结构之后，你借助这个过程，有选择地引入一些重复的数据，以促进特殊性能需求的实现。steve hoberman的“反向规范化生存指南”给如何适当增加冗余提供了一套可计算的评分标准。通过考察每个关系的6个问题，累加各个问题的得分之后，当得分大于等于10时，我们将对该关系进行反向规范化。
“反向规范化生存指南”的计分规则：
1.关系是什么类型的：该问题确定我们所分析的关系的类型。父实体对于子实体具有什么样的关系？
层次关系(20分)
同等关系(-10分)
确定关系(-20分)
2.参与率是多少：该问题确定一个关系中的每个实体的参与性。换句话说，对于一个给定的父实体数值，大概会有几个子实体数值？父与子的关系越接近“一对一”，我们对它进行反向规范化的机会就越大。
多达“一对五”的比率(20分)
多达“一对一百”的比率(-10分)
超过“一对一百”的比率(-20分)
3.父实体中有多少个数据元素
少于10个数据元素(20分)
数据元素的数量介于10到20之间(-10分)
多于20个数据元素(-20分)
4.使用率是多少：当用户需要来自子的信息时，通常情况下，它们是否还需要来自父的信息呢？换句话说，这两个实体的耦合或相关程度如何？
相互之间的关联很强(30分)
相互之间的关联较弱或者没有关联(-30分)
5.父实体时一个占位符吗：在不远的将来，我们是否还打算向父实体加入更多的数据元素或关系？如果答案是“不”，那么进行反向规范化的可行性就更强。
是(20分)
不(-20分)
6.变动对比率是多少：该问题是为了确定，在同一时间周期内，两个实体的插入和更新的频度是否相近。如果其中一个实体很少变化，而另一个实体却变动频繁，那么，我们就非常倾向于保持它们的规范化状态，把它们放在各自的表中。
相同(20分)
不同(-20分)
“反向规范化生存指南”的使用方法：
1)把模型中的关系按照优先级排序
2)选择一个关系
3)对这个关系回答提问
4)如果得分等于或大于10，就进行反向规范化
5)返回步骤二，直到完成所有的关系。
第九章：抽象化安全指南和组件
看过我的“浅谈数据库设计技巧(上) ”的朋友应该还记得我举的第二个例子：网上电子商务平台上的商品信息表的设计。本章将我在上面例子中所用的方法上升到了理论阶段，采用了面向对象的设计，将所有商品的共有属性提取出来，抽象成一个超类，再加入一个表来记录各个不同实体之间的细节来实现超类的派生，从而实现设计的灵活性。当出现下面两种条件的任何场合，抽象化都是极其有用的：
设计需要永久维持下去：要求以后尽可能的不修改数据库设计
需求可能发生变化：应用程序的需求发生变化，而要求业务流程重组或进行功能升级
数据仓库：当新的分类类型从源应用程序中传过来时，我们无须对数据仓库的设计进行任何改动，而只需在分类类型实体加入一个新行即可
元数据仓储库：和数据仓库的要求类似
当然，抽象化会大大增加工作量和开发的复杂度，而人们通常关注的是非常短期的应用和眼前的成本，而不关心将来的高得多的成本。所以，我非常赞同敏捷软件开发这个观点：在最初几乎不进行预先设计，但是一旦需求发生变化，此时作为一名追求卓越的程序员，应该从头审查整个架构设计，在此次修改中设计出能够满足日后类似修改的系统架构。
“抽象组件”就是小型的抽象模型片段，在许多的建模场合(无论是什么行业、组织，甚至什么主体域的建模场合)中，它们都可被反复使用。在键模阶段多次使用抽象化之后，你将开始看到出现的抽象化结构的趋势。这些“抽象组件”有如下的目的：
加快设计速度
加快开发速度
提供通用且有用的机构
第十章：数据模型美化技巧
本章通过关注如何改进逻辑和物理数据模型的视觉外观，使我们的设计超越直接的应用程序需求。本章中讨论了五个类别的美化技巧：
逻辑数据元素排列技巧：这些技巧是一个推荐的、对你的逻辑数据模型中的每一个实体的数据元素进行排序的方法。
物理数据元素排序技巧：这些技巧关注数据模型中每一个实体的最佳布局。
实体布局技巧：这些技巧关注数据模型中的每一个实体的最佳布局
关系布局技巧：这些技巧关注如何调整重叠的关系线条以及看起来穿越（而不是绕过）无关实体的关系
吸引注意力的技巧：这些技巧关注如何在我们的涉及中突出的某些元素、实体或关系。
第十一章：规划一个长盛不衰的数据建模生涯
对数据建模者的十大忠告清单：
1)记住：灵活性、准确性和背景
2)建模只是你的工作的一小部分
3)尝试其他角色
4)了解95/5规则：95%的时间将花费在5%的数据元素上
5)数据建模从不令人厌烦：如果你一直在做数据建模工作，而且发现自己经常感到厌烦，那么，你的确该改变一下了。这可能不是数据建模领域本身令人厌烦，而是你所在的特定的任务、公司或行业不再令人兴奋。冒险一下，尝试着道一个不同的项目或行业中进行数据建模工作吧！
6)站在技术前沿
7)尽量不要在模型上牵扯感情因素：建模者必须理解，人们在评审过程中的意见并不是针对模型的创建者，而是针对这个模型的内容。即那句老话：对事不对人。
8)让你的创造力展开翅膀：在考虑记录数据需求和改进设计的新方法时，要紧可能有创造性。有创造性也许就意味着修改本书中的某些工具。这还可能意味着提出你自己的电子表格或其他工具。
9)单纯的理论太昂贵了：在设计活动过程中，你要确保把这个观点牢记在心。为这个应用程序掏腰包的部门和组织期望看到的是能看得着的实用结果。
10)成为一个了不起的会讲故事的人：作为一名数据建模者，讲故事是工作的一个很重要的部分。为了帮组教化和影响项目经理以及对我们行业缺乏理解的其他人，我们需要讲故事或趣闻。
最后，我个人觉得，steve hoberman所提出的“抽象组件”的观念和面向对象设计中的的“设计模式”非常类似。即数据库专家在多次的数据建模后，将各个项目中的类似部分抽象化，提取出特定的建模模型片段，以后只需在新的项目中对这些模型片段细化派生，即可快速构建出适合于该项目的数据库架构。不过，这些建模模型片段并没有统一，形成标准，目前也没有出版这类的书籍。本人正在陆续总结自己在这方面的经验，但是自知水平有限，不敢在高人面前班门弄斧，只希望自己日后陆续发布的相关文章能起到抛转引玉的作用，争取由中国的程序员率先统一出数据建模领域的“设计模式”。
