这么建模型，你就错了 演讲者：俞如富 职位 ：BI主管 来自公司：富士通（福建）

研讨 模型建设中的问题有哪些？ 时间：3分钟 （可结合案例）

摘要 案例简述及分享案例目标 案例背景及隐藏问题 怎么做？ 尝试办法及RIO分析 案例启示 1 2 3 4 5

案例:智慧社区数据中心建设项目 案例分享目标 2个月 完成数据建模 1个月 完成ETL建设 108张报表分析需求 案例分享目标 案例简述 智慧社区数据中心建设项目，要求在3个月内建设完成包括数据建模及ETL建设，并在完成数据中心一期建设后，2个月内完成100多张的数据分析报表需求。 分享目标：结合场景案例及当时遇到的困难和问题和对策解决过程来分享建模过程中的一些经验。主要目标体现在以下两点： 1.了解并进一步认识在不同的应用场景中建模型需要考虑的要素及问题 2.能结合案例掌握如何在需求变化、业务数据发展中调整建模的策略和思路 进一步认识在不同的应用场景中建模型需要考虑的要素及问题 能结合案例掌握如何在需求变化、业务数据发展中调整建模的策略和思路

摘要 案例简述及分享案例目标 案例背景及隐藏问题 怎么做？ 尝试办法及RIO分析 案例启示 1 2 3 4 5

需求变化频繁 设计变化频繁 临时性任务多 案例背景及隐藏问题 1.用户无法提出明确需求 2.要分析的数据维度信息变化大 ETL建设因DB表设计变化频繁，导致经常加班改ETL相关代码 设计变化频繁 临时性报表查询分析需求多，建了一堆的表，数据“增长”额外加了60%以上 临时性任务多 案例背景及隐藏问题

摘要 案例简述及分享案例目标 案例背景及隐藏问题 怎么做？ 尝试办法及RIO分析 案例启示 1 2 3 4 5

数据模型建设计划甘特图

怎么做到的 1.双向沟通方面 注重用户和软件开发人员的有效沟通，尤其在业务需求分析需要注意。 2.建模方法方面 利用维度建模建设思路应对将来可能的分析需求，结合PD建模工具(早期有借助ERWin建模工具) 3.抓重点，理顺优先级 做好对建模过程的痛点分析，在进度赶，投入少的情况下，我们要重点解决业务的痛点问题，才能产生最大的价值。

实践1. 如何更高效的做好业务需求分析？ 方向思路： 1.改变用户参与度不够的问题，意识->态度->行为的改变. 2.建立业务领域模型之间的关系，超越“功能需求”，做好开发与用户对实际问题的抽象。 3.用做产品的心态来做项目 具体措施： 1.用户访谈、调查调研 2.用户使用场景梳理，明确问题在哪里？怎么发生的问题 3.利用原型法来确定或引导用户需求，评估项目中可能的问题 概念模型设计举例

数据模型的框架（概要） 参与者主题域是指系统的所有用户，覆盖：政府、社区管理者、志愿者、电信/运营商、商家、居委会/物业、居民等； 服务主题域是指由参与者提供的所有服务，覆盖：服务、商品、产品等； 内容主题域是指系统内的所有内容信息，覆盖：新闻、通知公告、文档、图片、媒体等； 交互主题域是指参与者之间所关联的事件，覆盖：交易、共享、沟通、信息推送等； 地域主题域是指自然要素与人文因素作用形成的综合体，覆盖：地域空间；

3.结合应用设计好维的层次设计（年/季/月/旬/周/日 ？） 实践2. 维度建模的技巧 1.保留历史信息应对历史记录分析 2.预留扩展设计，应对维度应用扩展，保证模型关系完整性 3.结合应用设计好维的层次设计（年/季/月/旬/周/日 ？）

2.1缓慢变化维的3种类型如何选择? 返回 ID:111 ID:111 添加新的记录 Name:老王 Address:Addr1 Version:1 ID:111 Version:2 添加新的记录 Name:老王 Address:Addr1 Name:老王 Address:Addr2 Name:老王 Address:Addr1 Effective Start Date:2007-4-21 Effective End Date:Now Name:老王 Address:Addr2 Effective Start Date:Now Effective End Date:Null 更新为 ID:111 ID:111 ID:111 Version:1 返回 1.保留历史信息应对历史记录分析 Name:老王 Current Address:Addr1 Old Address:Null Name:老王 Current Address:Addr2 Old Address:Addr1 Name:老王 Address:Addr1 Effective Start Date:2007-4-21 Effective End Date:Null

参与人概念模型设计 参与人概念模型 参与人自然化 组织多样化（支持各种行业） 家庭聚类化 角色权限参数化 用户多样化（支持不同平台）

添加内容

摘要 案例简述及分享案例目标 案例背景及隐藏问题 怎么做？ 尝试办法及RIO分析 案例启示 1 2 3 4 5

为了建模而赶模型 为了进度而赶进度 And曾经尝试的办法及问题 团队曾走过的弯路： 1.见招拆招 需求多变，不考虑新增需求与过去需求的业务关联性，建一堆的表来应对 2.自以为是 不跟更多的与用户的深入沟通、调查和确认，忽略业务专家和数据分析专家的建议来建模，以开发方便快捷为出发解决问题。 尝试后的问题： 投入了时间精力、人工成本，但最后付出了高成本、低质量、无法满足后续的扩展性需求，表面是刚开始事情做少了，简单了，实际是复杂了问题，也让后续的维护时间、维护成本及开发工作量成倍增加。 为了建模而赶模型 为了进度而赶进度 核心问题

案例ROI分析 1.因该项目分两期，第一期遇到的问题在第一期形成了规范并做了经验和教训总结，在第二期的改进中， ETL的开发成本节省了50%。 2.把业务建模部分放到最重要的位置，也就是以用户业务问题为核心，构建模型，先慢后快，模型的稳定性和可读性和完整性二期比一期好，模型设计效率比一期快了40%左右，人工成本也在一期的基础上节省30%左右。 3.新增需求的响应速度情况，二期比一期的响应速度提升200%，满意度提高到90%以上。

摘要 案例简述及分享案例目标 案例背景及隐藏问题 怎么做？ 尝试办法及RIO分析 案例启示 1 2 3 4 5

案例启示 提炼出该案例（或项目）的哲理、方法论。 数据建模，许多人都过分关注建模的速度及建模技术，而缺少对需求建模，需求也是需要建模的，而且需求分析的原型，将直接影响模型的复杂度、可扩展性及灵活性。 在ETL建设过程中，工程师最怕的就是针对数据模型经常随业务变化，ETL就要经常改代码，返工等。其实我们的ETL也可以建模，而且ETL的模型建设得好，可以快速适应业务模型的变化，甚至许多时候在业务模型变化的时候，我们只需要控制ETL的输入变量来管理，有效的节省ETL的工作量。 许多公司做不好数据建模，有时是因为主动性不够，怕流程牵涉众多生产线麻烦，怕跟领导同事沟通被评价很LOW，怕被领导骂，在三怕的基础上，又被要求在极短的时间内要做好数据分析、要有数据挖掘的价值体现，于是许多模型就做得不叫模型，没有思想，也没有规律，纯粹为了迎合老板的“需求”而建了一堆没用的表。  满足用户的需求，并在使用上去引导用户。同时，也要明确不是所有需求都能在模型中实现，要考虑分阶段，分期实现的可能性。

对建模过程的3种过程方法进行比较总结 方法1：数据驱动 方法2：业务驱动 方法3：数据和业务一起进行 优势 1.先有数据整合可对数据选择和准备做更好的管理，在数据质量管理方面有优势 2.数据的维度信息都有准备，可快速进行分析应用的扩展 因为面对应用，因此分析应用可立竿见影，快速满足需求 1.逐步深化的建设方法，兼顾了效率和可扩展性 2.分析应用也可快速见效 挑战 1.数据整合投入较大，短期内投入产出比没有太大优势 2.需要具备符合业务规则且成熟的数据标准和数据模型 1.一般能满足的用户群体狭窄，普遍都是部门集，缺少全局的考虑，更多偏向功能的开发。 2.数据质量无法保障 1.团队的有效分工与协作要求更高 2.业务规划方向需统一一致 适用 方向 数据基础较好 有成熟数据建模经验 业务简单或是业务应用需求非常明确 业务线复杂，数据基础水平不一，应用需求层次不同

不以解决用户业务问题的模型建设都是耍流氓 模型建设是集业务、技术和数据分析应用于一体的脑力活 不以解决用户业务问题的模型建设都是耍流氓 诚谢大家的关注和聆听！