数据建模与DB设计

作者：	[韩] 金范编
页数：	136
定价：	34.00

出版社：	上海科学技术出版社
出版时间：	2016-10
购买地址：	京东当当

我是最优雅的杀手，不杀人专杀狗于 2017-04-25 10:03已经看到

第3章范式化（normalization）和反范式化（de normalization） 3.2反范式化

选择范式化形态的数据结构，还是选择保管生成时间的数据，尽量减少实体间关联，最大限度地保障信息查询性能的反范式化数据结构，最终都需根据业务规则作出选择。

3.2.2 实体的合并于分离

［1］实体的分离
大部分情况下，实体的分离会在范式化过程中将数据集合尽可能地因式分解后分离为多个实体，但也存在不违背范式化因数据处理导致必须分离的情形。

例如：关于具有大量属性的特定实体，访问的主要数据处理仅主要访问相应实体的部分属性，于此相反，也存在其余属性仅在不重要的处理中偶尔访问的情形以及某些属性虽输入了大部分数据值，但几乎不含特定属性数据值的情形。

我是最优雅的杀手，不杀人专杀狗于 2017-04-24 11:02已经看到

第3章范式化（normalization）和反范式化（de normalization） 3.2反范式化

3.2.1属性重复
如果访问特定实体信息时应一起看的主要属性存在于其它实体中，则关联实体获取相应信息，这种处理给整体系统性能带来负担时，可使所需属性在实体中重复或创建派生属性使用。特别是为了访问主要对应实体的特定属性值实体件频繁发生关联时，需要使用重复属性，这种重复属性主要发生于像实际实体一样积累数据历史纪录的实体中，这是因为查询数据时所需要的信息是数据生成时的信息而非当前时间的信息，因为若想关联生成时间信息，则会导致输入输出增加。

我是最优雅的杀手，不杀人专杀狗于 2017-04-23 22:31已经看到

第3章范式化（normalization）和反范式化（de normalization） 3.2反范式化

如果一个属性不存在于一个以上实体中而是直接反映在数据设计中，则范式化建模能促使数据维护工作有效进行，但查询所需信息的业务流程有时也会关联多个实体，成为降低处理速度的原因。因此如果须在欲构建的系统中考虑主要流程性能，则需考虑范式化的逆向工作－－－反范式化。

因此反范式化时有必要计算数据变更和维护时因反范式化而产生的追加成本和数据查询时产生的成本减少部分，将整个性能提高的程度大致数字化。

我是最优雅的杀手，不杀人专杀狗于 2017-04-21 15:01已经看到

第3章范式化（normalization）和反范式化（de normalization） 3.1范式化

第一范式是指在一个实体内有一个以上的属性重复，定义多个同类属性时，消除这种属性重复，使相应属性作为单独的实体独立出来。

第二范式是“属于一个实体的全部属性必须对全部唯一键具备从属关系”。换句话说，也就是“特定实体内的属性从属于部分唯一键而非全部唯一键时，相应属性并非特定实体内的属性”。如果存在即使仅改变部分属性值而非全部唯一键也定会受到影响的属性，则该属性并非当前实体的属性。因此第二范式可能仅对由两个以上属性构成的唯一键使用。

第三范式是：实体内的属性中，因非唯一键的属性而受到数据值影响的属性须分离为其他实体的属性。

我是最优雅的杀手，不杀人专杀狗于 2017-04-20 15:03已经看到

第3章范式化（normalization）和反范式化（de normalization） 3.1范式化

初期分析阶段制定的逻辑erd 须能最为准确地看出所需业务数据，其主要目的是能够与相关人员沟通，数据结构须范式化。范式化主要在构建逻辑数据模型的初期阶段实施。可以说是判定业务中使用的数据结构是否有逻辑地构建标准。用一句话概括实施这中范式化的最终目的，就是“一个属性必须仅存在于一个实体中”，可以说这是与物理角度考虑性能后实施的反范式化相反的概念。

范式化过程是尽可能地展开数据结构，构建最容易理解的数据结构，是借此检查何处的分析不妥当，是否存在遗漏的实体与属性的最佳方法。范式化理论上分为5步，但实物中国主要以3步为目标去实施；

1.消除属性的重复
2.尽量从属于全部唯一键
3.尽量不从属于非唯一键属性

我是最优雅的杀手，不杀人专杀狗于 2017-04-18 17:42已经看到

第2章数据建模流程 2.4导出属性（attribute）

如果将主要实体的导出，关系设定以及唯一键的设置等一系列过程比喻成物流业务中为实现物品有效出入库的业务流程性能与适当安排，管理物品的效率而创建整体框架的工作，那么现在将要提到的导出属性可以说是在给定的框架下填充详细内容的过程。

属性的种类

［1］属性大体可分为单位属性，复合属性，派生属性，复合属性四种。

属性的验证

［1］相同名称的不同属性

［2］不同名称的相同属性

［3］是属性，还是实体

我是最优雅的杀手，不杀人专杀狗于 2017-04-13 18:28已经看到

第2章数据建模流程 2.3选定唯一键（unique identifier）

2.3.2 人造键的使用

人造键指的是仅由实体内构成的业务属性构成唯一键不合适时，人为创建任意属性将其作为唯一键使用，主要使用流水账号。业务中使用人造键更有利时，我们需要考虑两点。

［1］父型/子型实体中不存在具有唯一性的共同属性时。

多个子型实体构成的父型实体中虽存在各子型实体内唯一属性但不存在能够使用于全部子型实体的共同唯一属性时，虽然可以组合多个属性保障唯一性，但此前须考虑使用人造属性设置唯一键。

［2］必须组合任意多个列时

我是最优雅的杀手，不杀人专杀狗于 2017-04-11 22:48已经看到

第2章数据建模流程 2.3选定唯一键（unique identifier）

唯一键是能够区别实体中个体的属性集合。最上级主要实体的唯一键大部分标准是仅用一个属性即可区别个体唯一性，但其下级实体在大多数情况下一般需要两个以上的属性来区别个体唯一性。

为了保证历史记录的主要实体中个体的唯一性，最可靠的办法是唯一键中包含相当于有效期的有效起始日期与有效的终止日期，但有效终止日期是个体信息变更时必须进行变更的属性，故而无法包含在唯一键中。

简而言之，唯一键中包含的属性未来有可能变更或可能会发生业务上的变更需求时，唯一键中必须排除该属性，最好考虑使用人造键。

主要实体的唯一键须从多个角度充分考虑后明确提出，而且必须选定与建模操作相关的参与者能够首肯的候选。

另记：构建数据库时还需要考虑一点是，唯一键在构建数据库时相应属性会自动创建索引，因此构成唯一键的属性顺序构成索引。因此从性能角度来看，须牢记人造键会创建一个无意义的索引。

我是最优雅的杀手，不杀人专杀狗于 2017-04-04 23:19已经看到

第2章数据建模流程 2.2设定关系（relationship）

2.2.2 设定关系时的原则
或许有人会说“数据模型好似会动的生物”，这是因为数据模型反映业务规则的结果，由于业务规则的不断变化，数据模型自然会不断变化。但一旦数据模型确定，日后变更数据结构会很困难。因此确定数据结构时必须将未来可能会出现的业务规则的变更要素考虑在内，尽可能构建主要数据结构不会发生改变的数据模型，这点尤为重要。

1.关系是对属于集合的个体间业务规则的定义。
设定实体间的关系时指设定属于实体的个体间的关系，关系并非存在于某些通常的既定规则中，而是必须要依据相应业务规则设定实体间的关系。

2.关系中不包含时间线。
这里指明特定时间是因为，设置个体间的关系时有时会因为历史记录数据管理问题导致不考了时间，仅单纯地区分个体间的关系，从而导出错误的关系。

3.勿对无数据变更的历史记录实体设定关系。

我是最优雅的杀手，不杀人专杀狗于 2017-04-03 04:07已经看到

第2章数据建模流程 2.2设定关系（relationship）

关系图式的解释

ERD中使用的关系图是双向表示实体与实体间关联性的方法，大体可分为三种进行说明。

1 可选性表示实体数据间是否始终存在关系

2 元数表示特定实体中一个个体与对应实体的几个个体是否存在关系

3 关系名表示实体双方间业务上是否存在某种关系，使用在业务中使用的有意义的名称

我是最优雅的杀手，不杀人专杀狗于 2017-03-30 23:36已经看到

第2章数据建模流程 2.2设定关系（relationship）

关系是特定时间属于数据集合的个体间的纽带，表现个体间的关联性，是确保数据集合间完整性的工具。从业务流程角度来看，类似于前往查找所需数据之路。如果存在过多的，复杂的，重复的数据关系，那么维护管理将需要支付大量费用。同时给掌握业务数据结构带来困难。正如实体是根据业务规则创建的数据集合那样，设定关系也是反映业务规则。对于初学建模的人而言，设定关系是比较困难的工作。

我是最优雅的杀手，不杀人专杀狗于 2017-03-28 22:58已经看到

第2章数据建模流程 2.1导出实体（entity）

2.1.3 实体分析方法

进行数据建模时会有豁然了解全部基本核心实体的那一刻。如果据此导出基本实体，关系，属性，则可以绘制出ERD。通常，在经验不足的状态下找出实体时，则会采用按照查找顺序罗列出来，边随时移动或修改ERD边建模。如果业务范围较广时也以此方法绘制关系图，则必须经常费力修改，ERD的整体复杂程度增加，让人很难理解，因此业务负责人会感到混乱，建模员想要向某人说明时也将花费大量时间。在数据分析方法中，还有一种至上而下方法，该方法先确定数据的上集合，再据此细分出下级数据集合，即使进行业务分析时导出了新实体，也仅需修改某一集合的部分集合即可解决。不仅很容易在ERD中反映出来，而且所有人都能轻松理解，因此可确保顺利沟通。

对于初期的ERD图，比起注重哪个是正确答案，更须侧重那个能实现相互间有效沟通。

我是最优雅的杀手，不杀人专杀狗于 2017-03-27 20:00已经看到

第2章数据建模流程 2.1导出实体（entity）

2.1.1 选定实体候选
如果上级建模时必须存在的实体在分析中未导出，那么实体间的关系可能会发生扭曲，在下级阶段中也会出现执行错误。因此建模初期为了找出重要实体并设定关系必须投入大量时间。事实上主要实体必然会需要核心业务负责人的积极参与，建模员必须通过多种现有的资料与面谈，快速进行基础业务数据分析。业务数据分析中能够成为本源的几点代表性事项：
1 现有系统中管理的表布局

2 保存一定期限内的报告或业务资料

3 业务处理流程图的数据存储库

4 类似行业其他公司系统的实体

5 业务负责人的面谈

我是最优雅的杀手，不杀人专杀狗于 2017-03-26 18:32已经看到

第2章数据建模流程 2.1导出实体（entity）

2.1.1 实体定义

实体时保管数据的集合单位。定义实体指的是定义实体中包含的数据集合的范围，故而必须详细记述业务数据的范围而非单纯描绘词典中的含义，实体名须使用能够代表实体定义中所记述内容的适当术语。

实体的定义是对看待数据的观点整合。因此因业务作用不同导致看待数据的视角也不同时，需要整合，统一这些视角的过程与流程。特别是主要实体的定义与分类方法等牵扯到多个业务组织的利害关系，调节这些关系的操作非常重要。如果各部门的商品定义不同，看待的个体单位也不同。就会增加构成数据与业务流程的复杂性。

实体定义是能够知晓数据建模程度的标尺。如果草率地定义属于实体的数据结合，则可以认为建模也很草率。关于主要实体，必须尽力明确记述业务中何种条件的数据属于哪个实体。

我是最优雅的杀手，不杀人专杀狗于 2017-03-26 12:35已经看到

第1章数据建模概述 1.3业务理解的重要性

数据模型指的是“表现业务中使用的数据结构的设计图”。因此，为了确立数据结构，必须有准确了解相应业务知识的核心业务负责人的积极参与。虽然业务负责人了解需要何种数据，但他们无法了解何种数据应以何种形态构成，如何构成。换句话说，他们在理解数据方面存在明显局限。

虽然对业务流程的理解程度并非数据建模的绝对要素，但它严重影响确定数据结构的过程。进行数据建模时，为了明确业务领域中使用的数据并通过适当沟通导出要求，充分审核现有现有数据与新要求数据从而做出明确的设计，数据建模员必须理解业务流程。
未能充分理解业务知识的数据建模员咋完成建模后离开，之后才发现关键问题该怎么办呢？数据结构的问题会再次泛滥成混乱的数据。而数据建模的质量问题最终必然会留下来的业务负责人与系统操作者，让他们承担后果。这不仅仅时交接层面的问题，更需要我们转变思维，转变认知，即“这是我的工作，建模的质量由我定”“建模员时帮组我的人”

我是最优雅的杀手，不杀人专杀狗于 2017-03-25 21:28已经看到

第1章数据建模概述 1.4建模的基本规则

端正数据建模员的作用

不要自己决定，让大家去决定！这是数据建模员的正确姿态必须做出所有人都能达成一致意见的决定，即使不能如此，也要拥有让大家对建模员的决定可协商一致的领导能力。只有如此，方能称为真真意义上的数据专家。

业务负责人被之前经验所束缚造成偏见，以一己之力统领数据建模，程序员或程序分析员为了达到个人目的影响数据结构或因所谓强权业务部门的利害影响数据结构，则数据模型必将面目全非。之所以产生这种情况，是因为数据建模员自己不是领导也不做决定。

数据建模员必须在各种专家主张自己的见解时起到协调领导作用。建模员必须根据多种形态的数据结构预测可能会对流程与数据管理产生何种影响，并对此进行充分说明。

我是最优雅的杀手，不杀人专杀狗于 2017-03-25 12:24已经看到

第1章数据建模概述 1.2数据模型的必要性

随着数据分析方法论的发展，人们提出了数据模型概念随着应用系统构建方法的计算机辅助软件工程工具开始流行，数据模型的必要性也开始体现出来
以数据为中心的系统构建方式的重要性进一步显现出来。随着数据建模经验的积累，数据建模开始正式应用于大型业务系统中，人们对数据的认识也发生巨大的变化。

如果了解有关数据模型的功能性知识并不了就数据结构如何影响实际业务处理，则实施有效的建模时必然会心有余而力不足。

为了应对业务场景不断的变化和要求，必须从长远观点构建IT基础设施。从这个角度来看，可以说为了实现超越现实，面向未来的数据管理，系统化的数据模型是必不可少的。

我是最优雅的杀手，不杀人专杀狗于 2017-03-23 22:37已经看到

第1章数据建模概述 1.1数据模型的概念

业务中使用的数据模型即：了解何种数据由何人使用，如何使用，将数据分类整理，保管，对相互关联的数据设定关系，从而使人能够轻松联系起来查找并获取数据。

随着数据逐渐增多，各处的数据会发生重复且很难维持数据准确性，必然会导致难以有效地管理数据因为这种现实情况，看待数据的角度必须是数据本身，导出业务所需的集合后，再划分出具体的集合，进而导出集合间的业务关联性，这被称为以数据为中心的业务分析，这种以数据为中心的处理方法正成为系统构建的标准。

为了保持以单纯的角度看待数据，需要将业务中产生的数据全体集合进行具体划分。尽可能地看待业务数据时，则全部业务都有能够交易的商品，都有产生交易该商品的主体。主体间的交易一定存在几种形态的合同，以此合同为依据发生实际交易，而合同则由主体，交易场所等数据构成。

我是最优雅的杀手，不杀人专杀狗于 2017-03-22 21:29已经看到

第5章数据建模实例 5.1上位实体的设定

在建模初期阶段，定义各业务共同的主要数据集合并设定数据结构是极其重要的事项，占据建模过程中一半以上的作业内容，在这个阶段如何定义上位实体集合将会影响全体数据结构。在这个阶段与其逐一确认详细数据视图找出正解，不如集中解决如何符合逻辑地表示各业务流程中主要数据的数据结构。特别是业务跨越多个领域时，区分好共同部分和各领域的持有数据是一件格外重要的事情。

==未完待续===

我是最优雅的杀手，不杀人专杀狗于 2017-03-19 11:06已经看到

第1章数据建模概述 1.7自上而下式（top down）建模与自下而上式（bottom up）建模

自上而下的式建模是指先导出必须在数据库中存储的个体后再导出属性并设定关系，是制定ERD的方法。因此该方法需要先与非常了解相应业务的相应人员进行业务协商，而后以协商后导出的内容为标准导出个体，设定导出个体间的关系。为导出的个体追加适当的属性。自下而上式建模是分析当前用户正在使用的与业务相关的票证，格式，管理台账，相关文件等后制定ERD的方法。

目录

手机绑定