数据库设计经验分享.ppt

数据库设计经验分享 数据库培训系列 * 抽象 抽象思想 抽象过程 经验技巧 流程规范 实例讨论 抽象 抽象思想 * 吃饭 需求：作为一名某种类型的用户，我希望达成某些目的，这样可以开发的价值 睡觉 打豆豆…… @呼吸 @消化 @神经 @血液循环 @内分泌…… 分析 抽象过程概述 * 需求 聚焦于待开发系统的边界，描述系统的功能和性能 用例图 用例文档 分析 提炼核心机制（找实体、找属性、找关系，复用） 类图、ER图 序列图 设计 核心与非核心结合，实现系统（性能、安全、扩展） 数据库设计文档 代码 抽象过程概述-需求 * 用例名称：编辑基本信息 执行者：专区管理员 前置条件：管理员已登录并且进入基本信息编辑页面 后置条件：系统返回专区管理首页 涉众利益： 基本路径： 1. 系统展示当前的专区基本信息 2. 专区管理员编辑要更新的基本信息 3. 系统实时验证信息合法 4. 专区管理员提交编辑后的基本信息 5. 系统保存基本信息 6. 系统展示保存结果 扩展： 字段列表：基本信息(专区名称、专区logo、……) 业务规则：不能和“亲兄弟”专区同名、…… 非功能需求：页面要符合前台管理的整体风格、…… 设计约束：用户上传的logo图片不能大于100K、…… 抽象过程概述-分析 * 抽象 经验杂谈 把数据表分类 了解数据库设计范式 牢记“三少”原则 利用数据冗余 提升性能的总结 其他 流程规范 实例讨论 经验杂谈 经验杂谈—把数据表分类 * 不同类型的表有不同的数据规模估算、查询频次估算和使用方式 不同类型的表可以针对性制定不同的设计、使用原则 分类的目的： 配置表 资源表 业务表 事务表 统计表 历史表 经验杂谈—了解数据库设计范式 * 构造关系型数据库必须遵循的规则——范式 ? 第一范式对属性的原子性约束，要求属性具有原子性，不可再分解； ? 第二范式对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性； ? 第三范式对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余。? 在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑 经验杂谈—牢记“三少”原则 * ? 表的数量越少越好只有表的个数少了，才能说明系统的E－R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计 ? 表中组合主键的字段个数越少越好主键是实体的高度抽象，主键与外键的配对，表示实体之间的关系；组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间? ? 表中的字段越少越好概念单一化、一事一地；只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余 “三少”原则是相对的，不是绝对的，主要目的是防止滥打补丁。 经验杂谈—利用数据冗余 * 主键与外键在多表中的重复出现不属于数据冗余，非键字段的重复出现才是数据冗余 非键字段的重复出现是低级冗余，字段的派生是高级冗余 冗余会提高读取速度，但是低级冗余会增加数据的不一致性，因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余) 经验杂谈—提升性能的总结 * 在数据库物理设计时，适当降低范式，增加冗余，少用触发器，多用存储过程，合理创建索引 当计算非常复杂、而且记录条数非常巨大时，把复杂计算放到数据库外面实现，比如用C++模块处理完成之后，才入库追加到表中去 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。如，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过30个，则垂直分割该表，将原来的一个表分解为两个表 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数 学会SQL语句调优和高效语句的写法 要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫 经验杂谈—其他 * 主键是实体的高度抽象，外键体现实体之间的关系，两者是对数据模型的高度抽象，因此键的设计非常重要。一般而言，一个实体不能既无主键又无外键 如果两个实体之间存在多对多的关系，则应该将关系也生成实体，消除直接的多对多关系 客观世界和数据库实体之间的映射关系可以是一对一、一对多、多对一、多对多的关系 视图可以对基表数据综合展示，并且对数据安全很有帮助 抽象 经验杂谈 流程规范 设计规范 设计评审流程 实例讨论 流程规范 流程规范 * 数据库设