读DAMA数据管理知识体系指南11数据建模(下)

打印 上一主题 下一主题

主题 997|帖子 997|积分 2991


1. 规范化

1.1. 规范化(Normalization)是运用规则将复杂的业务转化为规范的数据结构的过程
1.2. 范式化的基本目的是保证每个属性只在一个位置出现,以消除冗余或冗余导致的不一致性

  • 1.2.1. 整个过程需要深入明白每个属性,以及每个属性与主键的关系
1.3. 规范化规则根据主键和外键整理属性

  • 1.3.1. 规范化规则可归类到不同规范层次,对每一个层次可应用更细的方式和规范性来搜索正确的主键和外键
  • 1.3.2. 每个级别由一个独立的范式组成,并且每个相继级别不需要包含以前的级别
2. 范式的层次

2.1. 第一范式(1NF)

  • 2.1.1. 确保每个实体都有一个有效的主键,每个属性都依赖于主键,而且消除冗余的分组,以确保每个属性的原子性(不能有多个值存在)​
  • 2.1.2. 第一范式包罗了与通常称为关联实体的附加实体的多对多关系解析
2.2. 第二范式(2NF)

  • 2.2.1. 确保每个实体都有最小的主键,每个属性都依赖于完备的主键
2.3. 第三范式(3NF)

  • 2.3.1. 确保每一个实体都没有隐藏的主键,每个属性都不依赖于键值之外的任何属性(仅依赖于完备的主键)​
  • 2.3.2. 模子的规范化通常要求达到第三范式水平即可
2.4. Boyce/Codd范式(BCNF)

  • 2.4.1. 解决了交叉的复合候选键的问题
  • 2.4.2. 候选键是主键或备用键
  • 2.4.3. 复合意味着不止一个(如一个实体主键有两个属性)​,交叉是指键与键之间隐藏着业务规则
2.5. 第四范式(4NF)

  • 2.5.1. 将全部三元关系分解成二元关系,直到这些关系不能再分解成更小的部门
2.6. 第五范式(5NF)

  • 2.6.1. 将实体内部的依赖关系分解成二元关系,全部联结依赖部门主键
2.7. 实践中BCNF、4NF、5 NF很少出现
3. 抽象化

3.1. 抽象化(Abstraction)就是将细节移除,这样可以在更广泛的环境下扩展适用性,同时保存概念或主题的紧张和本质属性
3.2. 抽象包罗泛化(Generalization)和特化(Specialization)

  • 3.2.1. 泛化将实体的公共属性和关系分组为超类(Supertype)实体
  • 3.2.2. 特化将实体中的区分属性分离为子类(Subtype)实体

    • 3.2.2.1. 这种特化通常基于实体实例中的属性值

3.3. 超类也可以使用角色或分类创建子类,将实体的实例按功能分离到组中
3.4. 子类关系意味着超类的全部属性都被子类继续

  • 3.4.1. 在数据模子中,子类可以淘汰冗余
4. 规划数据建模交付成果

4.1. 图表(Diagram)

  • 4.1.1. 一个数据模子包含多少个图表,图表是一种以精确的方式描述需求的情势
  • 4.1.2. 需求可以描述不同具体程度的层级(如概念、逻辑或物理模子)​、采用的数据模子(关系、维度、对象、基于究竟的、基于时间的或NoSQL)​,以及实例中采用的表示方法(如信息工程、同一建模语言、对象角色建模等)​
4.2. 定义(Definitions)

  • 4.2.1. 实体、属性和关系的定义对于维护数据模子的精度至关紧张
4.3. 争议和悬而未决的问题(Issues and Outstanding Questions)

  • 4.3.1. 数据建模过程常常出现大概无法解决的一些争议和问题
  • 4.3.2. 负责解决这些争议或回答这些问题的人员或团队通常位于数据建模团队之外
  • 4.3.3. 通常数据建模工作交付的文档应包含当前的议题和未解决的问题
4.4. 血缘关系(Lineage)

  • 4.4.1. 血缘关系是指数据从那里来,颠末什么样的加工,变成了什么样的效果的脉络关系
  • 4.4.2. 血缘关系会以来源/目的映射的情势呈现,这样就可以相识到源系统的属性以及它们如何被迁移至目的系统
  • 4.4.3. 血缘关系还可以在同一建模过程中,追踪数据模子层级
  • 4.4.4. 有助于数据建模人员深入明白数据需求,准确定位属性来源
  • 4.4.5. 确定属性在源系统中的环境,这是验证模子和映射关系准确性的有效工具
5. 建立数据模子

5.1. 要研究现有的数据模子和数据库
5.2. 参考已发布的建模标准和数据标准
5.3. 搜集和考虑随时提出的新的数据要求
5.4. 在此基础上建模人员计划数据模子初稿
5.5. 再与业务专家和业务分析师确认及讨论模子计划是否符合业务规则要求,同时提出修改建议
5.6. 由建模人员举行修改
5.7. 反复举行,直至没有任何问题为止
5.8. 需要通过持续改进实践来控制模子质量
5.9. 数据模子需要保持最新的状态

  • 5.9.1. 需求或业务流程发生变革时,都需要对数据模子举行更新
  • 5.9.2. 在结束开发迭代时,一个好的习惯是对最新的物理数据模子举行逆向工程,并确保它与相应的逻辑数据模子保持一致
  • 5.9.3. 许多数据建模工具可以自动比较物理模子与逻辑模子差别
6. 正向工程

6.1. 指从需求开始构建新应用程序的过程

  • 6.1.1. 需要通过建立概念模子来明白需求的范围和核心的术语
  • 6.1.2. 建立逻辑模子来具体描述业务过程
  • 6.1.3. 通过具体的建表语句来实现物理模子
6.2. 概念数据模子建模

  • 6.2.1. 选择模子类型

    • 6.2.1.1. 从关系、维度、基于究竟或者NoSQL的建模方法中选择一种来举行建模

  • 6.2.2. 选择表示方法

    • 6.2.2.1. 一旦选定了建模的模式类型,接下来就该考虑采用何种建模表示方法

  • 6.2.3. 完成初始概念模子

    • 6.2.3.1. 初始概念模子主要目的是获取用户的观点
    • 6.2.3.2. 不要试图将该组用户的观点与其他部门去匹配而使这个流程复杂化

  • 6.2.4. 收集组织中最高级的概念(名称)

    • 6.2.4.1. 主要包罗时间、地点、用户/会员、商品/服务和生意业务

  • 6.2.5. 收集与这些概念相关的活动(动词)

    • 6.2.5.1. 关系可以是双向的,也可以涉及多个概念

  • 6.2.6. 合并企业术语

    • 6.2.6.1. 一旦数据建模人员获取了某些用户的观点,接下来需要确保这些观点与企业的术语和定义相一致

  • 6.2.7. 获取签订

    • 6.2.7.1. 初始模子完成后,确保对模子举行最佳实践及需求满意程度的评审
    • 6.2.7.2. 通常采用电子邮件方式发送给各人,如果看起来是准确的就充足了

6.3. 逻辑数据模子建模

  • 6.3.1. 分析信息需求

    • 6.3.1.1. 为确认信息需求,需要在多少业务流程中确认业务信息需求
    • 6.3.1.2. 业务流程所要消耗的信息可定义为输入,而其他业务流程的输出可定义为信息产物
    • 6.3.1.3. 不管流程还是数据都是以顺序或并发的方式举行计划
    • 6.3.1.4. 需求分析包罗业务需求的引导、组织、记录、评审、美满、允许和变更控制
    • 6.3.1.5. 逻辑数据建模是表达业务数据需求的紧张本领
      6.3.1.5.1. 图片胜于千言万语

    • 6.3.1.6. 书面的数据需求说明书使用需求管理工具来维护
    • 6.3.1.7. 任何此类文档的内容收集规范都应该与数据模子捕获的需求同步,以便于举行影响分析

  • 6.3.2. 分析现有文档

    • 6.3.2.1. 分析现有与建模有关的档案(包罗已计划的数据模子和数据库)对建模工作是一个很好的开始
    • 6.3.2.2. 即使现有的数据模子文件已过时,或与实际生产系统存在较大差别,有价值的部门也会对新模子的计划提供很大帮助
    • 6.3.2.3. 务必向相关专家确认其每个细节的准确性和时效性,以确保新模子计划的准确性

  • 6.3.3. 添加关联实体

    • 6.3.3.1. 关联实体(Associative Entities)用于描述多对多关系
    • 6.3.3.2. 关联实体从关系中涉及的实体获取标识属性,并将它们放入一个新的实体中
    • 6.3.3.3. 在维度建模中,关联实体通常被称为究竟表

  • 6.3.4. 添加属性

    • 6.3.4.1. 将属性添加到概念实体中
    • 6.3.4.2. 逻辑数据模子中的属性具有原子性,它应该包含一个且只有一个数据(究竟)​,不能被再次拆分

  • 6.3.5. 指定域

    • 6.3.5.1. 域(Domains)的作用是保证模子属性中格式和数值集的一致性

  • 6.3.6. 指定键

    • 6.3.6.1. 分配给实体的属性可以是键属性,也可以是非键属性
    • 6.3.6.2. 键属性有助于从全部实体实例中识别出唯一的实体实例,可以是单独一个属性成为键,也可以是与其他键元素组合的部门键
    • 6.3.6.3. 非键属性描述实体实例,但无法唯一标识该实例
    • 6.3.6.4. 需要识别主键和备用键

6.4. 物理数据建模

  • 6.4.1. 逻辑数据模子需要举行修改和调整以形成物理数据模子,并使得最终的计划在存储应用程序中运行良好
  • 6.4.2. 解决逻辑抽象

    • 6.4.2.1. 子类型吸收(Subtype Absorption)
      6.4.2.1.1. 子类型实体属性作为可空列,包含在表示超类型实体的表中

    • 6.4.2.2. 超类型分区(Supertype Partition)
      6.4.2.2.1. 超类型实体的属性包含在为每个子类型创建的单独表中


  • 6.4.3. 添加属性细节

    • 6.4.3.1. 向物理模子添加具体信息
    • 6.4.3.2. 定义每个列或字段的物理域、物理数据类型和长度
    • 6.4.3.3. 为列或字段添加得当的约束(如允许为空和默认值)​,尤其是对于“NOT NULL”的约束

  • 6.4.4. 添加参考数据对象

    • 6.4.4.1. 创建匹配的单独代码表
      6.4.4.1.1. 据模子的不同,这些代码表数量也不一样

    • 6.4.4.2. 创建主共享代码表
      6.4.4.2.1. 对于拥有大量代码表的模子,可以将全部的代码表合并到一张表中
      6.4.4.2.2. 意味着更改一个引用列表将对整个表产生影响
      6.4.4.2.3. 应该避免代码值的冲突

    • 6.4.4.3. 将规则或有效代码嵌入到相应对象的定义中
      6.4.4.3.1. 为对象嵌入的规则或列表代码创建约束,对于仅用作其他对象引用的代码列表


  • 6.4.5. 指定署理键

    • 6.4.5.1. 给业务分配不可见的唯一键值,与它们匹配的数据没有任何意义或关系
    • 6.4.5.2. 这是一个可选步骤,主要取决于自然键是否够大或是复合值,以及其属性是否分配了大概随时间变革的值

  • 6.4.6. 逆规范化

    • 6.4.6.1. 逆规范化或添加冗余可以极大地提高性能,远凌驾了重复存储和复制处理的成本
    • 6.4.6.2. 维度模子主要采用逆规范化的本领

  • 6.4.7. 建立索引

    • 6.4.7.1. 索引是用于访问数据库数据的过程中优化查询(数据检索)性能的另一个选择
    • 6.4.7.2. 在许多环境下,索引可以提高查询性能
    • 6.4.7.3. 要尝试在大表上构建索引,使用最频繁引用的列(特殊是键,包罗主键、备用键和外键)来实现最常运行的查询

  • 6.4.8. 分区

    • 6.4.8.1. 充分考虑整个数据模子(维度)的分区计谋,尤其是当究竟包含许多可选维度键(稀疏)时
    • 6.4.8.2. 在理想环境下,建议在日期键上举行分区
      6.4.8.2.1. 如果无法做到这一点,则需要根据分析效果和工作负载举行研究,以提出并改进后续分区模子


  • 6.4.9. 创建视图

    • 6.4.9.1. 视图可用于控制对某些数据元素的访问,也可用于嵌入公共连接条件或过滤器,以实现常见对象或查询的标准化
    • 6.4.9.2. 视图本身应该是需求驱动的
      6.4.9.2.1. 需要对照逻辑数据模子和物理数据模子的开发流程来创建视图


7. 逆向工程

7.1. 逆向工程是记录现有数据库的过程
7.2. 物理数据建模通常是第一步,以相识现有系统的技术计划
7.3. 逻辑数据建模是第二步,以记录现有系统满意业务的解决方案
7.4. 概念数据建模是第三步,用于记录现有系统中的范围和关键术语

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

玛卡巴卡的卡巴卡玛

金牌会员
这个人很懒什么都没写!
快速回复 返回顶部 返回列表