敏捷数据—数据库设计和开发.pptxVIP

敏捷数据—数据库设计和开发 主要内容 还是要谈一些理论 实用技巧 延伸思考 谈一些理论 如何建模数据 识别数据实体 一个实体可能表示一组人、地点、事物、事件或概念 识别属性 应用命名规范 识别关系 组成关系（商品列表是订单的一部分） 活动关系（客户下订单，客户居住于地址） 应用数据建模模式 分配键 自然键 代理键，自增还是GUID、UUID 建议：优先选择代理键、避免‘智能’键、考虑为简单的查找表（一般不变的代码表）分配自然键、你的应用必须还要支持‘自然键查找’ 数据规范化 为什么规范化 规范化可带来高度内聚和松散耦合的数据方案 信息被存放在一处且仅一处 第一范式(1NF) 当一个实体类型不包含重复的数据组，可认为符合INF 第二范式(2NF) 当一个实体类型为1NF并且所有的非键属性全部依赖于他的主键，可认为符合2NF 第三范式(3NF) 当一个实体类型为2NF并且所有属性都直接依赖于它的主键，可认为符合3NF 决策及建议 策略：永远权衡利弊，非规范化能提高性能 对操作型数据库规范化，报表数据库采用非规范化 类规范化 为什么规范化 好的设计是高内聚和松耦合的 第一对象范式(1ONF) 当一个属性所需的具体行为被封装在所属类的内部，可认为符合IONF 第二对象范式(2ONF) 当一个类为1ONF并且该类的多个实例所需的‘共用’行为被封装在所属类的内部，可认为符合2ONF 第三对象范式(3ONF) 当一个类为2ONF并且其仅封装一组内聚的行为，可认为符合3ONF 如：日期范围、国家、邮编、地址、金额等 决策及建议 策略：永远权衡利弊，非规范化能提高编码和对象访问的方便性 执行规范化会比较好的和数据架构对接 认识和数据架构的耦合问题 你应用程序的源代码 其他应用程序的源代码 数据装载源代码 数据提取源代码 持久化框架、层 数据库本身 数据迁移脚本 测试代码 文档 解决之道：封装 认识对象-关系的阻抗失配 原则上的差异： 面向对象范型是基于经过验证的软件工程原则 关系数据库则是基于经过验证的数据原则 访问方式的差异： 使用对象范型可以通过对象关系进行遍历 关系范型通过对表的连接 建模者思维模式的差异： 类模型，要考虑数据和行为 数据建模只考虑数据 细微的差别就更多了 如：我们在对象模型会建立一个邮政编码的类来存储邮政编码并校验它，但他在表中是一个列 对象-关系映射 最佳用对象模型驱动数据模型 映射继承（人、客户、员工、管理人员） 每个层次体系一个表 每个具体类一个表 每个类一个表 通用方案 映射关系（员工、部门、任务） 一对一 一对多 多对多 单向 双向 如何更好地进行数据建模 实践、实践、再实践 学习、学习、再学习 提出工作中的问题并通过实践和学习寻找答案 实用技巧 最佳实际-特殊列设计 主键 使用代理键，整数还是GUID、UUID 通用对象化实体主键读 无特殊情况下使用整数表示代码或状态 构建信息的显示列（可以是计算列） 主要实体加入特殊列 DeletionState CreatedOn、CreatedBy ModifiedOn、ModifiedBy Version 实体层、对象层为显示排序做准备 独立设计 通用设计 对象设计 最佳实际-结构设计 树状信息设计 使用映射表 使用层次途径 扩展信息设计 单一扩展表 多个扩展表 通用结构 使用模板表 简化配置（如：ECP的Bug跟踪流程，高速联合监控中各种设备的配置） 简化操作 使用通用表存储通用数据结构 地址等 使用单个表简化多种实体的存储 日历表等 使用通用内部代码、状态名称查找表 支持多种语言版本 使用元数据存储管理实体 实体-属性-关系-标签-存储过程 流程和业务数据分别存储 最佳实际-视图、存储过程、索引 使用视图查看、和报表的信息源 实体类保持只读的Label列 使用标量函数来减少参数的复杂性 当天、当月、上月等 恰到好处的使用索引 正确使用集聚索引（不要用主键做聚集索引） 存储在不同的目标上 区分报表的类别 基于‘操作型数据’的报表必须回答‘当前在发生是么什么’，如：XX当前的票证库存是多少？ 如果是其他情况，需要考虑从‘报表型数据’ 报表处理 引入聚合表，减少表关联 使用缓存（一级缓存、二级缓存） 进行表分区 使用合适的索引 禁用事实报表 最佳实际-对象、关系、编码 解决对象关系阻抗，引入中间机制 大而强的ORM 或介于DAO和ORM之间的中间解决方案 对象层区分，未处理（填写）和Null的区别 所有非主键查询永远返回一个集合 查询结果，没有必要总是用业务对象或值对象 国际化的项目应该注意的问题：Label 、时间 只是用只读缓存 核心表保持时间戳以支持开放式并发 最佳实际-其他 只在一个地方调整数据库结构，并生成升级脚步，保持日志 充分利用数据库本身的能力，如：分区