客户数据质量评价的原则与方法
客户数据质量评价的原则与方法
admin 2013-10-12
关于客户数据质量的困惑
什么样的客户数据质量是比较好的？”为什么我们的客户数据看起来很不错，可是在进行电话营销时，客户接触率和营销效果确差强人意，与期望大相径庭？”在进行数据库营销的讨论和交流中，经常有人问到这样的问题。
这些问题反映出了很多在从事数据库营销或直复营销过程中的营销策划人员和运营管理人员经常面临的问题和困惑。
几乎所有的组织都需要数据，一些行业严重依赖于客户数据，如银行、电信、保险公司等。毫无疑问，较差的数据质量给企业营销带来的损失非常巨大！试想一下，如果你的呼叫中心正在试图向非目标客户进行大规模电话营销活动，或是你的企业正向那些早已过期的邮寄地址寄出了数以万计的促销宣传资料。这些给公司带来的损失有多少？不幸的是，这样的情况几乎经常发生，而企业的数据库营销策划人员也经常面临着数据选择和评价的挑战。
理解关于质量的涵义
首先，让我们简单探讨一下质量”的涵义。
在服务营销和服务管理中，通常将质量”定义为：满足不同客户的个性化需求的能力”。这样的定义有着一定的主观特征，也就是说不同的企业会根据其对客户需求和竞争环境的理解，来定义其产品与服务的质量特征。这可以用来解释为什么对于不同等级的客户提供的服务质量标准有所差异的原因，这也是为什么同样是提供点对点的航空运输服务，某些航空公司的服务质量和客户体验要好于其他一些竞争者的原因。
国际标准组织将质量定义为：产品或服务所具备的满足明确或隐含需求能力的特
征和特性的总和”。这样的定义虽然更明确，但对于大多数的人来说，过于专业和抽象。
一个比较通俗且受到多数人认可的对质量的直观定义是适合使用需求”。这也是我们本文的一个主旨，没有质量绝对完美的数据，对于数据质量的评价也是要根据数据的使用需求来进行评价的。只要能够适合使用的需求，我们就认为数据的质量是符合要求的。企业也应当本着有取有舍的原则，选择那些为企业所能利用的数据。
了解了质量的定义，接下来就可以进入客户数据质量的评价话题了。
数据质量评价的基本原则
评价数据质量有着一些通用的基本原则，这些原则在进行数据库营销或是数据分析
时经常采用。一般来说，以下六点是评价数据质量时的最主要的原则：
1. 正确性。正确性主要是指数据的来源是否正确，数据的来源是否可以被证实。不准确的客户数据产生的原因很多，有时是因为采集时的录入错误，也可能是在存贮或转换的过程出错，或是老化的数据没有更新或重新标定造成的错误。不准确的
数据的另外一种形式是由于应用系统中对数据域的误用，或者是由于与数据相关的
定义不一致而导致了数据不是其所代表的含义。
2. 完整性。完整性是指客户数据要求记录的信息是否完整，是否没有缺失。客户数据项缺失的原因可能是没有采集，或是缺失了。数据缺失通常会造成错失营销机会、甚至导致营销决策错误。数据不完整的另一个原因是要求的信息没有被识别出来，如通过身份证件号码可以获知客户的性别和年龄。
3. 一致性。指数据在应用或维护时是否被一致的定义和理解，在不同的列表中，
或是不同的使用人员应当对于列表的数据有着相同的认识，或是说同一列表中的同
一数据项表达着相同的含义。
4. 完备性。指分析或营销所需要的数据信息是否都存在，不会因为某些信息项目缺失造成对营销或分析的影响。
5. 有效性。指数据是否在符合使用需求的可接受范围内，数据是否在符合使用需求的时间范围内采集或维护的。。不及时的和过时的数据都是无效的。
6. 适用性。指数据是否在时间上、空间上和内容上符合企业营销活动的使用需求。有时也指数据本身被获取、理解或使用的可能性。
高质量的数据具备以下的一些特征：
1. 数据列表采集过程规范，记录项目准确
2. 客户数据列表的记录项目完整，没有缺失的记录项
3. 在客户数据列表中的字段项被统一的定义和解释，在整个数据库中保持一致
4. 数据存贮的格式规范，没有冗余字段或无效字段
5. 数据列表最近刚刚进行过清洗，而且数据的有效率和准确率较高
数据质量为什么会变差
数据总是不完美的。
客户数据是动态的，对于一个特定的客户来说，客户转换工作、搬家、变更联系方式等情况都会造成客户联络信息的变化。
企业数据同样也是如此，企业更名、搬迁、联系人变更、电话号码变更等等，都会造成企业数据的质量变化。而在一些破产率较高的行业或是创业成长型企业，企业数据的更是经常发生变化。
进行数据抽样测试
数据本身并没有内在意义，数据仅描述了所发生事件的部分事实，并不提供对事件的判断或解释。数据本身无法说明其自身是否重要或准确。
在大规模进行数据库营销或是营销分析之前一定进行数据样本的抽样测试，通过抽样测试的结果来判断数据的质量。
如何抽样？抽样比例是多少？这是在谈到数据抽样时经常被问到的问题。通常都会建议企业根据列表的样本总量和重要程度，采用系统抽样的方式。
营销客户数据的哪些数据项是最关键的
企业营销的目标客户主要包括消费者和企业客户两类。客户信息一般包括三种类型：描述类信息，行为类信息和关联类信息。直复营销用到的消费者信息主要是客户描述类信息中的联络信息和人口统计信息。企业客户信息主要是企业联络信息和
经济统计信息。
关键的信息就是那些在营销中或是客户分析中的关键信息。比如，电话营销中的客户联系电话，直邮营销中的邮编和邮寄地址，在一些特定产品营销中用到的客户人口统计信息，如性别、年龄、收入、住所等等。
本文围绕客户数据列表最常用的一些字段项，如联系电话、邮寄地址、身份证件号码等营销中常用的信息项，来简单说明客户数据质量判断的技巧。
方法一：客户数据列表的数量
客户数据列表的数量是一个非常关键的质量评价指标，客户数据列表的规模大小经
常能够反映出数据列表所有者的数据采集质量和维护水平。能够定期维护庞大客户数据列表的服务商无疑是更有保证的，这不仅需要大量的人员和资金投入，而且同时也数据库营销专业能力的一种体现。
比如说，在一个拥有五十万汽车的大城市，一个只包含两万左右汽车拥有者的列表无疑只是其中的很小一部分，如果没有特定的汽车品牌型号或是购车时间等其他更
有价值的信息，这样的列表的价值还是要打折扣的。
方法二：客户数据列表的采集方式
了解客户数据列表的采集方式对于判断数据的质量有着重要的作用，有时客户自己填写的数据信息往往要比企业主动采集来的数据更准确，数据采集时的时间紧迫程
度也是影响采集数据质量的一个原因。
对于一些只有注册成为会员，才能进入网站的注册会员记录来说，有些人为了加快网站的注册过程，经常填写与事实不符的信息，这些信息的可信度和准确性就有疑问。一些街头采访或促销活动积累的客户数据，其准确性也经常达不到预期的质量。
电话调查得来的数据，前几项内容的准确性往往要比最后几项的准确性更高。
我就见到过这样一个客户列表，列表中客户性别的数据项，统计发现共中的绝大部分客户的性别都为男性，事实上客户列表的男女比例是基本相当的，只是男性稍多些。深入调查才发现，原来在信息采集时，系统默认的客户是男性，很多信息录入人员并没有对这一状态根据客户的真实性别进行更新，由此带来这一列表的这一字
段基本不能反映客户的真实性别状态。当针对某一特定性别的客户群体进行营销时，这样的数据列表无疑会带来很大的损失。
从分散的系统数据库中合并得来的客户数据有时会由于数据一致性的问题，带来大量的数据质量问题。
方法三：客户数据列表的分类信息
前面提到过，客户数据列表的所有者对客户数据列表进行的分类越完善，数据列表的质量一般也越高。真正有价值的客户数据会淹没在大量未经分类的数据列表中而难以识别和充分利用。
比如，一个将企业联系人列表在按行业、地区和规模分类后，再细分为企业决策人员、企业办公产品采购人员、IT负责人、财务负责人、人事负责人等，这样的列表明显会比一个汇总的企业联系人列表更有价值。
方法四：客户数据列表的采集时间
了解数据的采集时间非常关键。数据的质量是动态的，数据的质量每天都在下降。
一般来说，只建议选择那些在一年以内采集的客户数据列表。
国外有统计显示，每个月有2%的客户信息过时，即每年有25%左右的客户信息会失效。
固定电话号码的升位信息和时间，固定电话局号的变更时间等，都可以作为数据采集时间
的辅助判断标准。
方法五：掌握客户数据信息的时效性
数据是有时效性。随着时间的变经，数据也不断的失效和失真。比如说，前一阵子媒体炒作的关于初生婴儿的数据，被一些婴儿产品或食品商利用来进行电话销售或
直邮的情况，这些数据就有着明显的时效性。
再比如说一些家装公司，非常希望能够得到的直接数据就是那些刚刚买了新房，而且在交房的前期，这时也是最好家装产品销售时机。
这些数据在过了一定的时期后，其准确性可能仍是准确的，但是对于这些销售商来说，已经失去了价值。
方法六：有效利用固定联系电话号码的特征
固定联系电话是最重要的营销信息之一，同时联系电话也包含着很多有价值的信息
来辅助进行客户数据列表的质量判断。
比如，通过固定电话号码的局号和辅助的位置信息，可以大致判断出固定电话的所在区域位置。通过固定电话码局号和列表数据的分布，也可以了解客户数据列表中客户的分布情况。一般来说，在商务区或是经济发达区域的固定联系电话很可能意味着更多的商机。
方法七：有效利用移动联系电话号码的特征
移动电话号码同样包含着很多丰富的信息，移动手机的号段不仅仅能够反映出客户
移动号码的所属行政区域，同时也能够从一定程度上反映出该号码的在市场上出现的使用时间。
利用移动电话号码号段能够反应号码所属行政区域的特征，也可以对客户数据列表的客户地域分布进行分析和判断。如果一个营销活动仅仅是针对本市的居民作为目
标客户的营销活动，那么那些拥有异地手机号码的客户就不能做为有效的目标客户。
一些先进的外呼软件和系统已经具备的号码过滤功能，能够根据营销规则的设定有效的限制和筛选出符合营销要求的电话号码。
方法八：掌握身份证件号码的规则
中国公民的居民身份证件号码包含着一些有价值的信息，如发证公安户政部门所属
的行政区划代码、出生年月日性别等信息。
客户数据质量评价的原则与方法
客户数据质量评价的原则与方法 admin 2013-10-12 关于客户数据质量的困惑 “什么样的客户数据质量是比较好的？”“为什么我们的客户数据看起来很不错，可是在进行电话营销时，客户接触率和营销效果确差强人意，与期望大相径庭？”在进行数据库营销的讨论和交流中，经常有人问到这样的问题。 这些问题反映出了很多在从事数据库营销或直复营销过程中的营销策划人员和运营管理人员经常面临的问题和困惑。 几乎所有的组织都需要数据，一些行业严重依赖于客户数据，如银行、电信、保险公司等。毫无疑问，较差的数据质量给企业营销带来的损失非常巨大！试想一下，如果你的呼叫中心正在试图向非目标客户进行大规模电话营销活动，或是你的企业正向那些早已过期的邮寄地址寄出了数以万计的促销宣传资料。这些给公司带来的损失有多少？不幸的是，这样的情况几乎经常发生，而企业的数据库营销策划人员也经常面临着数据选择和评价的挑战。 理解关于质量的涵义 首先，让我们简单探讨一下“质量”的涵义。
在服务营销和服务管理中，通常将“质量”定义为：“满足不同客户的个性化需求的能力”。这样的定义有着一定的主观特征，也就是说不同的企业会根据其对客户需求和竞争环境的理解，来定义其产品与服务的质量特征。这可以用来解释为什么对于不同等级的客户提供的服务质量标准有所差异的原因，这也是为什么同样是提供点对点的航空运输服务，某些航空公司的服务质量和客户体验要好于其他一些竞争者的原因。 国际标准组织将质量定义为：“产品或服务所具备的满足明确或隐含需求能力的特征和特性的总和”。这样的定义虽然更明确，但对于大多数的人来说，过于专业和抽象。 一个比较通俗且受到多数人认可的对质量的直观定义是“适合使用需求”。这也是我们本文的一个主旨，没有质量绝对完美的数据，对于数据质量的评价也是要根据数据的使用需求来进行评价的。只要能够适合使用的需求，我们就认为数据的质量是符合要求的。企业也应当本着有取有舍的原则，选择那些为企业所能利用的数据。 了解了质量的定义，接下来就可以进入客户数据质量的评价话题了。 数据质量评价的基本原则
软件工程-数据库设计规范与命名规则
数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。 C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。 然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis， 简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一 DBMS 支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术， 用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示:
数据库设计方法及
数据库设计方法及命名规范
- - 2 数据库设计方法、规范与技巧 (5) 一、数据库设计过程 (5) 1. 需求分析阶段 (6) 2. 概念结构设计阶段 (9) 2.1 第零步——初始化工程 (10) 2.2 第一步——定义实体 (10) 2.3 第二步——定义联系 (11) 2.4 第三步——定义码 (11) 2.5 第四步——定义属性 (12) 2.6 第五步——定义其他对象和规则 (12) 3. 逻辑结构设计阶段 (13) 4. 数据库物理设计阶段 (15) 5. 数据库实施阶段 (15) 6. 数据库运行和维护阶段 (16) 7.建模工具的使用 (16) 二、数据库设计技巧 (18) 1. 设计数据库之前（需求分析阶段） (18) 2. 表和字段的设计（数据库逻辑设计） (19) 1) 标准化和规范化 (19) 2) 数据驱动 (20)
- - 3 3) 考虑各种变化 (21) 4) 对地址和电话采用多个字段 (22) 5) 使用角色实体定义属于某类别的列 (22) 6) 选择数字类型和文本类型尽量充足 (23) 7) 增加删除标记字段 (24) 3. 选择键和索引（数据库逻辑设计） (24) 4. 数据完整性设计（数据库逻辑设计） (27) 1) 完整性实现机制： (27) 2) 用约束而非商务规则强制数据完整性 (27) 3) 强制指示完整性 (28) 4) 使用查找控制数据完整性 (28) 5) 采用视图 (28) 5. 其他设计技巧 (29) 1) 避免使用触发器 (29) 2) 使用常用英语（或者其他任何语言）而不 要使用编码 (29) 3) 保存常用信息 (29) 4) 包含版本机制 (30) 5) 编制文档 (30) 6) 测试、测试、反复测试 (31) 7) 检查设计 (31) 三、数据库命名规范 (31) 1. 实体（表）的命名 (31) 2. 属性（列）的命名 (34)
空间数据质量特性与质量控制.
空间数据质量特性与质量控制 范志坚1，2,方源敏1,汪虹2 (1.昆明理工大学国土资源工程学院昆明 650093;2.云南省基础地理信息中心昆明 650034) 摘要：本文主要讨论空间数据质量特性、质量控制所涉及的内容。结合笔者最近从事空间数 据库建库的具体实践和工作体会，探讨从位置精度、属性精度、时间精度、数据完整性和逻辑一致性等方面对数据质量进行全面控制，最终建成一个质量可靠的空间数据库。 关键词：地理信息系统；空间数据库；空间数据；质量特性；质量控制 Quality characteristic and Quality control of Spatial data Fan Zhi-jian1，2，Fang Yuan-min1，Wang-Hong2 (1.Faculty of Land Resources Engineering，Kunming University of Science and Technology，Kunming 650093，China；2.Yunnan Provincial Geomatics center，Kunming 650034，China) Abstract：This paper mainly talks over contents which are involved with quality characteristic and quality control of spatial data．Integrating with concrete practice and work experience which the writer has recently been engaged in establishing spatial database,a very comprehensive control of data quality should be discussed from aspects of positional accuracy、attribute accuracy、temporal accuracy、data compression、as well as logic conformance and so on．Finally，a dependable spatial database should be set up． Key words：GIS；spatial database；spatial data；quality characteristic；quality control 0 引言 空间数据库是随着地理信息系统(GIS)的开发和应用而发展起来的数据库新技术，它是地理信息系统的重要组成部份，是地理信息系统应用部份的前题和基础。空间数据库为此建立了如实体、关系、数据独立性、完整性、数据操作、资源共享等一系列基本概念。以空间数据存储和操作为对象的空间数据库，把被管理的数据从一维推向了二维、三维甚至更高维。空间数据库是一种应用于空间数据处理与信息分析领域的具有工程性质的数据库，它所管理的对象主要是空间实体。在空间数据库中，空间数据质量的好坏，直接影响到空间数据库的经济效益和社会效益。 要得到高质量的空间数据，最重要的是在空间数据生产和使用过程中进行质量管理和质量控制。通过质量管理和质量控制，可以分析影响产品质量的原因，进而提高空间数据的质量。空间数据的质量是空间数据库生存和发展的保障，缺少质量指标的空间数据将无法得到用户的信任，且直接影响到地理信息系统应用、分析、决策的正确性和可靠性。由此可知，空间数据质量是空间数据库的生
DB设计01：数据库设计的重要性和设计原则
数据库设计的重要性和设计原则 发布时间: 2012-10-31 09:31 作者: wangpeng047 来源: 51Testing软件测试网采编 字体: 小中大| 上一篇下一篇| 打印| 我要投稿| 推荐标签：软件开 发数据库 说起数据库设计，相信大家都明白怎么回事，但说起数据库设计的重要性， 我想大家也只是停留在概念上而已，到底如何重要？怎么重要呢？今天就将我 至今为止的理解向大家阐述下。 一个不良的数据库设计，必然会造成很多问题，轻则增减字段，重则系统 无法运行。我先来说说数据库设计不合理的表现吧： 1、与需求不符 因为这个原因造成的改动量往往是最大。如果进入编码阶段的话，很可能 会直接让你崩溃掉。 2、性能低下 含有大数据量的表之间的关联过多；没有合理的字段设计来用于查询而造 成的SQL查询语句很复杂；对于大数据量的表没有采用有效的手段去处理；滥 用视图等。 3、数据完整性丧失 含有主外键关系的表之间关联字段的设计方式不合理，造成更新与删除操 作后程序容易出错或不完善；使用了已经删除或丢失掉的数据。 4、可扩展性性太差 表设计的与业务绑定的太紧密、单一，造成表的可拓展性、可修改性太差， 无法新需求的要求。 5、非必要数据冗余量太大 没用的垃圾数据存储过多，不仅占用资源，还影响查询效率。 6、不利于计算或统计
缺少必要的联系性或统计性字段或用于计算统计的字段分散于多个表中，造成计算统计的步骤繁琐，甚至无法计算统计。 7、没有详尽的数据记录信息 缺少必要的字段，造成无法跟踪数据变化、用户操作，也无法进行数据分析。 8、表之间的耦合性太大 多张表之间关联的过于紧密，造成一张表发生变化而影响到其他表。 9、字段设计考虑不周 字段长度过短或字段类型过于明确，造成可发挥、可拓展的空间太小。 大多数的程序员对于软件开发的出发点认识不是很明确，总是认为实现功能才是重要的，在简单了解完基本需求后就急忙进入编码阶段，对于数据库设计思考的比较少、比较简单，大多设计都只停留在表面上，这往往是要命的，会为系统留下很多隐患。要么是写代码开发过程中才发现问题，要么就是系统上线运转后没多久就出现问题，还有可能给后期维护增加了很多工作量。如果到了那个时候再想修改数据库设计或进行优化等同于推翻重来。 数据库是整个软件应用的根基，是软件设计的起点，它起着决定性的质变作用，因此我们必须对数据库设计高度重视起来，培养设计良好数据库的习惯，是一个优秀的软件设计师所必须具备的基本素质条件！ 那么我们要做到什么程度才是对的呢？下面就说说数据库设计的原则： 1、数据库设计最起码要占用整个项目开发的40%以上的时间 数据库是需求的直观反应和表现，因此设计时必须要切实符合用户的需求，要多次与用户沟通交流来细化需求，将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确，就要分析不确定的因素，设计表时就要事先预留出可变通的字段，正所谓“有备无患”。 2、数据库设计不仅仅停留于页面demo的表面 页面内容所需要的字段，在数据库设计中只是一部分，还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段，因此数据库设计绝对不是简单的基本数据存储，还有逻辑数据存储。
数据库表设计的几条准则
数据库表设计的几条准则 前言：数据库设计在平时的工作是必不可少的，良好的表设计可以让我们查询效率更高，加快网站访问速度，提升用户体验，并且方便于我们查询数据。本篇博客就来聚焦一下，如何设计出高可复用，优良的表结构，从而在实际的工作中使我们写出更好的代码。 数据库表设计的几条黄金准则： 一：字段的原子性 解释：保证每列的原子性，不可分解，意思表达要清楚，不能含糊，高度概括字段的含义，能用一个字段表达清楚的绝不使用第二个字段，可以用两个字段表达清楚的绝不使用一个 字段 二：主键设计 解释：主键不要与业务逻辑有所关联，最好是毫无意义的一串独立不重复的数字，常见的比如UUID或者将主键设置为Auto_increment; 三：字段使用次数 解释：对于频繁修改的字段（一般是指状态类字段）最好用独立的数字或者单个字母去表示，不用使用汉字或者英文 四：字段长度 解释：建表的时候，字段长度尽量要比实际业务的字段大3-5个字段左右（考虑到合理性和伸缩性），最好是2的n次方幂值。不能建比实际业务太大的字段长度，这是因为如果字段长度过大，在进行查询的时候索引在B- Tree树上遍历会越耗费时间，从而查询的时间会越久；但是绝对不能建小，否则mysql数据会报错，程序会抛出异常； 五：关于外键 解释：尽量不要建立外键，保证每个表的独立性。如果非得保持一定的关系，最好是通过id 进行关联 六：动静分离 解释：最好做好静态表和动态表的分离。这里解释一下静态表和动态表的含义，静态表：存储着一些固定不变的资源，比如城市/地区名/国家。动态表：一些频繁修改的表 七：关于code值 解释：使用数字码或者字母去代替实际的名字，也就是尽量把name转换为code，因为name 可能会变（万一变化就会查询处多条数据，从而抛出错误），但是code一般是不会变化的.另一方面，code值存储的字符较少，也能减少数据库的压力 八：关于Null值 解释：不要有null值，有null值的话，数据库在进行索引的时候查询的时间更久，从而浪费更多的时间！
空间数据质量在GIS中的影响
地理信息系统(GIS)的基础是空间数据，空间数据的核心是质量，空间数据的生产与质量控制是一个相互作用的过程，生产数据是为了应用，而数据质量是一个关系到数据可靠性和系统可靠性的重要问题。随着数据质量在建设数字地球、进行矿产预测的计算机模拟中发挥着越来越重要的作用，但如果空间数据的质量及其精度未能引起足够的重视，由这些空间数据进行重新运算和组合产生的空间数据就不是最终需要的结果，可能导致最终决策错误。要提高空间数据的质量，减小空间数据误差，就要对空间数据误差产生和扩散的所有过程和环节进行控制。在数据采集时对元数据进行跟踪，采取相应的措施提高数据质量。以地图数字化为例，对纸质地图进行数字化前应对其进行校正或配准，选用精度比较高的数字化仪和扫描仪提高栅格数据的精度等；根据空间数据质量评价的标准还应制定相应的细则来提高数据质量；对采集和处理空间数据人员进行岗前培训等也都能减小误差的传播。 1 GIS 空间数据质量控制研究现状 GIS 空间数据的质量优劣直接影响着GIS应用中分析结果的可靠程度及应用的真正实现，也影响着GIS产业的健康发展。因此，近年来国内外越来越关注GIS数据的精度和质量控制的研究。GIS数据的质量控制问题涉及面很广，包括数据质量的衡量标准、表示方法，数据误差的来源和性质，评价方法和控制方法及相关政策等。如政府部门积极制定法规保障数据质量；将数据作为产品，采用管理产品质量的方法管理数据质量；数据质量的教育、培训与咨询；初步形成了地理数据质量的系列国际标准，如ISO 19100系列标准中地理信息质量标准；方法上，主要成果和结论，包括直线不确定性模型的改进、曲线不确定性模型的建立；将平差理论引入GIS数据误差处理和质量控制，并提出了实用方法；对GIS 数字化误差的性质、分布进行了深入研究；从抽样检验的理论出发，探讨了GIS 产品的质量控制技术和方法。 2 空间数据质量的概念 2.1空间数据的质量 空间数据是有关空间位臵、专题特征以及时间信息的符号记录，而数据质量是空间数据在表达这3个基本要素时所能达到的准确性、一致性、完整性以及它们三者之间统一性的程度。由于现实世界的复杂性、模糊性以及人类认识和表达能力的局限性，空间数据在表达上不可能完全达到真值,只能在一定程度上接近真值。用户根据需要对空间数据的处理也会导致出现一定的质量问题。所以空间数据的误差产生于各种数据源及空间数据的输入和处理过程中。 2.2与空间数据质量相关的几个概念 2.2.1误差（Error）反映了数据与真实值或公认的真值之间的差异，它是一种常用的数据准确性的表达方式。
规范化-数据库设计原则
规范化－数据库设计原则 关系数据库设计的核心问题是关系模型的设计。本文将结合具体的实例，介绍数据库设计规范化的流程。摘要 关系型数据库是当前广泛使用的数据库类型，关系数据库设计是对数据进行组织化和结构化的过程，核心问题是关系模型的设计。对于数据库规模较小的情况，我们可以比较轻松的处理数据库中的表结构。然而，随着项目规模的不断增长，相应的数据库也变得更加复杂，关系模型表结构更为庞杂，这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的。更糟糕的是，由于表结构定义的不合理，会导致在更新数据时造成数据的不完整。因此，就有必要学习和掌握数据库的规范化流程，以指导我们更好的设计数据库的表结构，减少冗余的数据，借此可以提高数据库的存储效率，数据完整性和可扩展性。本文将结合具体的实例，介绍数据库规范化的流程。 序言 本文的目的就是通过详细的实例来阐述规范化的数据库设计原则。在DB2中，简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计，在以后的数据维护中，不会发生插入（insert）、删除（delete）和更新（update）时的异常。反之，数据库表结构设计不合理，不仅会给数据库的使用和维护带来各种各样的问题，而且可能存储了大量不需要的冗余信息，浪费系统资源。 要设计规范化的数据库，就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。但是一些相关材料上提到的范式设计，往往是给出一大堆的公式，这给设计者的理解和运用造成了一定的困难。因此，本文将结合具体形象的例子，尽可能通俗化地描述三个范式，以及如何在实际工程中加以优化使用。规范化 在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化使用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是"数据库规范化"。后面我们将通过实例来说明具体的规范化的工程。关于什么是范式的定义，请参考附录文章1. 数据冗余 数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中，因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。 规范化实例 为了说明方便，我们在本文中将使用一个SAMPLE数据表，来一步一步分析规范化的过程。 首先，我们先来生成一个的最初始的表。 CREATE TABLE "SAMPLE" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VARCHAR(200), "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER)
数据质量具体评测指标及方法说明
数据质量具体评测指标及方法说明 一、主要评测内容 重点评测个案库的数据完整性、逻辑关系准确性。评测内容及指标计算方法会根据需要作适当调整。 二、具体评测指标及方法 （一）主要数据项完整情况 1、评测内容：重点评测个案库中的基本情况表，具体数据项包括姓名、性别、现居住地代码、户籍所在地代码、公民身份号码、出生日期、婚姻状况、户口性质等8项必填内容。 其中：每条个案记录中，只要任意一项主要数据项缺失，即认定为该条记录的主要数据项不完整。 2、评测指标：主要数据项完整率 3、计算公式： 主要数据项完整的人口总数 —————————————×100% 个案信息库包含的人口总数 其中： 主要数据项要通过单项逻辑校验，没有通过单项逻辑校验的视为数据项缺失。校验规则如下： （1）性别、户口性质、婚姻状况数据项均不能为空错值；
（2）姓名：7岁以上（含7岁）“姓名”不含“未取名”、阿拉伯数字、英文字母等不符合规范的文字，不少于两个汉字。7岁以下人口不做此单项逻辑校验。 （3）公民身份号码：7岁以上（含7岁）“公民身份号码”不含空格、性别码与性别匹配、长度为15或18位、校验码正确。7岁以下人口不做此单项逻辑校验。 （4）出生日期：不大于汇总数据时点。 （5）现居住地代码：不为空错值，当人员类别为外出时，现居住地代码不应为本地 （6）户籍地代码：不为空错值，当人员类别为外来时，户籍地代码不应为本地 （二）逻辑关系准确情况 1、评测内容：分为单表审核、表间审核两种类型，共计7个审核内容。 其中，每条个案记录中，只要任意一项逻辑关系不准确，即认定为该条记录的逻辑关系不准确。 （1）若总人口数据“婚姻状况”为已婚（代码为20 – 23 29），则与配偶有关的信息项目配偶姓名、配偶身份证（配偶身份证错误也视为空）项均不为空； （2）育妇卡片“育龄妇女初婚日期”加15年不能小于“育龄妇女出生日期”；
11-个重要的数据库设计规则
11-个重要的数据库设计规则
?简介 在您开始阅读这篇文章之前，我得明确地告诉您，我并不是一个数据库设计领域的大师。以下列出的11点是我对自己在平时项目实践和阅读中学习到的经验总结出来的个人见解。我个人认为它们对我的数据库设计提供了很大的帮助。实属一家之言，欢迎拍砖: ) 我之所以写下这篇这么完整的文章是因为，很多开发者一参与到数据库设计，就会很自然地把“三范式”当作银弹一样来使用。他们往往认为遵循这个规范就是数据库设计的唯一标准。由于这种心态，他们往往尽管一路碰壁也会坚持把项目做下去。 如果你对“三范式”不清楚，请点击这里（FQ）一步一步的了解什么是“三范式”。 大家都说标准规范是重要的指导方针并且也这么做着，但是把它当作石头上的一块标记来记着（死记硬背）还是会带来麻烦的。以下11点是我在数据库设计时最优先考虑的规则。 ?规则1：弄清楚将要开发的应用程序是什么性质的（OLTP 还是OPAP）？
当你要开始设计一个数据库的时候，你应该首先要分析出你为之设计的应用程序是什么类型的，它是“事务处理型”（Transactional）的还是“分析型”（Analytical）的？你会发现许多开发人员采用标准化做法去设计数据库，而不考虑目标程序是什么类型的，这样做出来的程序很快就会陷入性能、客户定制化的问题当中。正如前面所说的，这里有两种应用程序类型，“基于事务处理”和“基于分析”，下面让我们来了解一下这两种类型究竟说的是什么意思。 事务处理型：这种类型的应用程序，你的最终用户更关注数据的增查改删（CRUD，Creating/Reading/Updating/Deleting）。这种类型更加官方的叫法是“OLTP”。 分析型：这种类型的应用程序，你的最终用户更关注数据分析、报表、趋势预测等等功能。这一类的数据库的“插入”和“更新”操作相对来说是比较少的。它们主要的目的是更加快速地查询、分析数据。这种类型更加官方的叫法是“OLAP”。 那么换句话说，如果你认为插入、更新、删除数据这些操作在你的程序中更为突出的话，那就设计一个规范化的表否则的话就去创建一个扁平的、不规范化的数据库结构。
数据质量评价模型的建立和实现
[摘要] 本文提出了数据质量评价模型、质量校验与评价方法，论述了“数据质量分析评价系统”的程序实现流程、总体结构及功能，介绍了系统的关键技术及进一步的研究方向。 [关键词] 质量模型质量检验质量评价 数据作为一种资源，是支撑信息化建设和应用的主体，根据“进去的是垃圾,出来的也是垃圾”这条原理,为了支持正确决策,就要求我们所管理的数据可靠,没有错误,能够准确地反映采油厂的实际情况。胜利采油厂数据中心存放了5千万条的数据，还在以每天2万条的速度加载，如何使这些海量数据在生产管理、科学研究、企业决策中发挥应有作用，使用户能用、敢用、愿用，使数据真正为企业服务，这是几乎所有信息化企业亟需迫切解决的问题。为解决数据质量问题，各种管理手段、技术手段和新的数据评价体系不断被应用在数据的采集和加工过程中。 一、数据质量评价模型的提出背景 采油厂的数据资源具有:横跨专业多，数据采集密度大、频度高，数据处理流程复杂等特点，为了保证数据的可用性，数据管理人员在客户端、服务器端均设置了数据质量审核规则，但是依然不可避免存在比例较高的数据质量问题，典型的有记录不全、数据遗漏、数据错误、多义字段、矛盾值、违背业务规则、无法关联等。产生数据问题的根本原因可以归结为以下几个方面: 1.没有从数据资源的战略高度对数据质量进行统一完整的定义，导致数据的分析评估没有统一可靠的标准； 2.数据质量还停留在定性评价,不能实现精确的量化评价，只是在业务需要某个数据时,才到库里去手动统计,无法动态记录某个单位、某个月的真实数据质量发生情况,导致数据质量考核缺乏可信的数据依据,大大影响考核力度; 3.没有一个能同时面对用户、专业部门、数据管理人员的可视化的数据质量监控评价平台,三方无法共享一个平台,共同实行数据管控一体化,导致业务规则的变更滞后,问题数据在库中的长期滞留; 4.也许有了N个业务模型,但是没有把它放到时间轴上去控制流程,导致实际生产中应该发生的活动的部分生产数据遗漏； 虽然影响采油厂数据质量的原因是多方面的，但主要的原因还是集中在管理、制度和数据采集加工规范化方面。对于如何通过管理、制度、标准和流程来控制数据质量,提高数据可信度,我们提出建立采油厂统一的数据质量分析评价模型，使用管理手段和技术手段相结合的办法,建立一套完善的数据定义、控制、评估流程，依托科学严谨的数据监督和质量控制体系持续地改进数据质量。 二、数据质量分析评价模型构成 构成数据质量分析评估模型的要素分别为:基础模型、数据质量辅助模型、数据质量定义模型、数据质量控制模型、数据质量评价模型。 1.基础模型。基础模型部分是整个模型框架的支撑核心部分，其他质量模型的定义和控制必须以基础模型中的计划和标准为依据。基础模型主要是映射、定义数据采集标准,上载分单位的采集计划,同时纳入了约束规则定义规范、控制规则定义规范、模板定义规范。 数据标准:分两部分,一部分是直接映射应用中的标准，例如源数据库标准;另一部分是针对新增应用库和项目库标准的定义规范,包括代码定义标准、数据项定义标准(例如是取英文还是汉语拼音,取几个字符）、值域定义标准等等新增表准的建立规范； 采集计划:采集单位的每月上载的日度、月度、年度的采集计划;
数据库设计方法、规范与技巧
数据库设计方法、规范与技巧 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（Structured Analysis，简称SA方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（Data Dictionary，简称DD）来描述。 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，高峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取方式｝ 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝ 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示: 2.1 第零步——初始化工程
数据表的设计原则
根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。 (1)不应针对整个系统进行数据库设计，而应该根据系统架构中的组件划分，针对每个组件所处理的业务进行组件单元的数据库设计；不同组件间所对应的数据库表之间的关联应尽可能减少，如果不同组件间的表需要外键关联也尽量不要创建外键关联，而只是记录关联表的一个主键，确保组件对应的表之间的独立性，为系统或表结构的重构提供可能性。 (2)采用领域模型驱动的方式和自顶向下的思路进行数据库设计，首先分析系统业务，根据职责定义对象。对象要符合封装的特性，确保与职责相关的数据项被定义在一个对象之内，这些数据项能够完整描述该职责，不会出现职责描述缺失。并且一个对象有且只有一项职责，如果一个对象要负责两个或两个以上的职责，应进行分拆。 (3)根据建立的领域模型进行数据库表的映射，此时应参考数据库设计第二范式：一个表中的所有非关键字属性都依赖于整个关键字。关键字可以是一个属性，也可以是多个属性的集合，不论那种方式，都应确保关键字能够保证唯一性。在确定关键字时，应保证关键字不会参与业务且不会出现更新异常，这时，最优解决方案为采用一个自增数值型属性或一个随机字符串作为表的关键字。 (4)由于第一点所述的领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，所以，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。 (5)同样，由于对象职责的单一性以及对象之间的关系反映的是业务逻辑之间的关系，所以在领域模型中的对象存在主对象和从对象之分，从对象是从1－N或N－N的角度进一步主对象的业务逻辑，所以从对象及对象关系映射为的表及表关联关系不存在删除和插入异常。 (6)在映射后得出的数据库表结构中，应再根据第四范式进行进一步修改，确保不存在多值依赖。这时，应根据反向工程的思路反馈给领域模型。如果表结构中存在多值依赖，则证明领域模型中的对象具有至少两个以上的职责，应根据第一条进行设计修正。第四范式：一个表如果满足BCNF，不应存在多值依赖。 (7)在经过分析后确认所有的表都满足二、三、四范式的情况下，表和表之间的关联尽量采用弱关联以便于对表字段和表结构的调整和重构。并且，我认为数据库中的表是用来持久化一个对象实例在特定时间及特定条件下的状态的，只是一个存储介质，所以，表和表之间也不应用强关联来表述业务（数据间的一致性），这一职责应由系统的逻辑层来保证，这种方式也确保了系统对于不正确数据（脏数据）的兼容性。当然，从整个系统的角度来说我们还是要尽最大努力确保系统不会产生脏数据，单从另一个角度来说，脏数据的产生在一定程度上也是不可避免的，我们也要保证系统对这种情况的容错性。这是一个折中的方案。 (8)应针对所有表的主键和外键建立索引，有针对性的（针对一些大数据量和常用检索方式）建立组合属性的索引，提高检索效率。虽然建立索引会消耗部分系统资源，但比较起在检索时搜索
数据质量评价的原则与方法
仅供参考！ 目前，基于数据仓库的商业智能应用已经成为国内许多企业的IT规划项目，并受到企业管理层的关注。作为商业智能的基础,数据质量的好坏是影响商业智能应用效果的关键，但由于企业的信息化经过长期的积累和发展,数据质量参差不齐，脏数据的存在阻碍了商业智能应用的进程，下面将重点谈谈如何让脏数据改头换面。 数据的“往事” 脏数据是指源系统中的数据不在给定的范围内或对于实际业务毫无意义，或是数据格式非法，以及在源系统中存在不规范的编码和含糊的业务逻辑。 脏数据的存在主要是由于源系统的设计不够严密造成的。主要表现为：数据格式错误，数据不一致，数据重复、错误，业务逻辑的不合理，违反业务规则等。例如，未经验证的身份证号码、未经验证的日期字段等，还有账户开户日期晚于用户销户日期、交易处理的操作员号不存在、性别超过取值范围等。此外，也有因为源系统基于性能的考虑，放弃了外键约束，从而导致数据不一致的结果。 目前，大多数的银行业务系统的输入界面是采用COBOL语言或C语言开发的，界面处理功能不是很强，一些要素被设计成“输入”而不是“选择”，如企业客户的信用等级被设计成输入，输入的正确与否完全由操作员的理解决定，这也是脏数据产生的原因之一。例如，如果被设计成“选择”就不会出现把AAA输成“1”或其他了。 转换与清洗的实例 下面以银行业务系统的客户的惟一标识—客户号为例来讲解如何转换与清洗数据。 客户信息的处理是整个数据抽取、转换、清洗和装载（ETL）工作中最复杂的部分。目前业务系统中常见的客户信息处理的难点主要有以下两个方面。 客户的惟一标识混乱 银行的客户号一般由证件类型与证件号组成，这里就有一个问题，如果客户有多种证件怎么办？或者说某个客户办了移民，有了新的身份，系统中怎样体现出他是同一个客户？这些问题，除了少部分是由于发证机关造成的（如身份证重号），大部分是由于操作人员的操作不规范造成的。主要表现在以下三个方面。 A、客户身份证号问题 最常见的问题是客户的身份证从15位更换为18位。首先操作人员只要能输入新的客户号，就认为是一个新的客户；其次，即使操作员知道客户的身份证升位了，但在银行的客户信息中，客户号是惟一标识，如果对惟一标识进行更新，作为增量反映到目标系统中，但没有记录原客户号，对于目标系统来说就是一条新记录，而删除原有的客户信息在实际操作中可能是不允许或做不到的，因为在这个客户号上可能还挂了许多账户，即便物理删除了这条客户
数据库设计和编码规范
数据库设计和编码规范 Version 1.0
目录 1简介 .................................................................................................. 1.1读者对象 ............................................................................................................................ 1.2目的.................................................................................................................................... 2数据库命名规范 .............................................................................. 2.1规范总体要求 .................................................................................................................... 2.2数据库对象命名规范 ........................................................................................................ 2.3变量命名规范 .................................................................................................................... 3数据库设计规范 .............................................................................. 3.1选择有效的设计工具 ........................................................................................................ 3.2表的设计 ............................................................................................................................ 3.2.1遵守范式要求 .................................................................................................... 3.2.2字段设计 ............................................................................................................ 3.2.3适当的合理的冗余 ............................................................................................ 3.2.4注意大类型的字段设计 .................................................................................... 3.3表关系和约束设计 ............................................................................................................ 3.3.1主键设计 ............................................................................................................ 3.3.2 外键设计 .................................................................................................................. 3.3.3 检查约束 .................................................................................................................. 3.4索引的设计 ........................................................................................................................ 3.4.1聚集索引和非聚集索引 .................................................................................... 3.4.2索引的初始创建原则 ........................................................................................ 3.4.3索引的注意事项 ................................................................................................ 3.4.4索引的后期维护工作 ........................................................................................ 3.5物理存储设计 .................................................................................................................... 3.5.1日志文件另外存放 ............................................................................................ 3.5.2存储空间的设计 ................................................................................................ 4T-SQL编码规范 ............................................................................. 4.1书写基本规范 .................................................................................................................... 4.2使用可搜索参数（WHERE使用原则）............................................................................ 4.3少用触发器和禁用游标 .................................................................................................... 4.4联合查询尽可能使用UNION ALL.................................................................................. 4.5尽可能避免的地方 ............................................................................................................ 4.6避免返回和使用多余的数据 ............................................................................................ 4.7操作符优化 ........................................................................................................................ 4.8数据库事务处理原则 ........................................................................................................ 4.9最少次数的访问表 ............................................................................................................ 4.10避免隐含的数据类型转换 ........................................................................................