资源描述
数据模型的基本概念 及建模方法论 NCR(中国)有限公司数据仓库事业部 崔大强 技术经理 内容安排 数据模型相关术语 什么是数据模型 建模注意事项 数据模型方法论 2 什么是数据模型？ 以数学的方式对现实事物的一种抽象表达,… 特征： 内容：描述了数据、及其之间的关系 形式：反映了数据的组织与管理形式 用途： (数据仓库)系统建设中的数据信息的蓝图 (数据仓库)系统建设的核心 业务人员与IT人员沟通的语言和工具 3 数据模型的分类 数据仓库项目中数据模型可以分为以下几种： Conceptual Data Model （CDM） 概念数据模型 Logical Data Model （LDM） 逻辑数据模型 Physical Data Model（PDM）物理数据模型 Application Data Model（ADM）应用数据模型 4 概念数据模型 Conceptual Data Model（CDM）概念数据模型 从全局上、宏观上介绍模型设计思路、范围和内容。 主要组成元素 主题 主题间关系 主题中的重要实体 实体间的相互关系 目标与用途 圈定建模的范围 划分建设主题 理清主要业务关系 构造逻辑数据模型的框架 5 定义： 使用逻辑建模语言 定义数据与数据之间的逻辑关系 以图形化的形式 反映客户的业务规则 达到数据组织的设计目标 逻辑数据模型 符号体系 设计内容 表现形式 反映内容 设计目标 6 逻辑数据模型 Logical Data Model （LDM） 逻辑数据模型 设计人员：业务人员、IT人员 设计目标 设计蓝图，指导整个数据仓库系统的建设 业务语言，业务人员与技术人员沟通的手段和方法 业务视图，独立于数据库技术实现 设计内容：实体、关系和属性 建模方法：3NF的设计方法 后续工作：物理数据模型的输入 7 物理数据模型 Physical Data Model（PDM）物理数据模型 设计目标：面向物理实施的具体细节 输入条件 继承于逻辑数据模型 依赖于所选择的数据库 决定于业务需求和性能之间的平衡 设计内容 数据库、表和字段、索引 需要作非正则化处理 后续工作：ETL、元数据管理和前端应用输入 8 应用数据模型 Application Data Model(ADM)应用数据模型 设计目标 满足最终用户对数据的访问（内容、形式要求） 满足应用系统对数据的存取（性能、存储要求） 主要特征 面向Power User和业务人员 与具体的应用相关 多维分析时一般采用星型结构或者雪花状结构 的设计方法 是事实表和维度表的组合 9 逻辑数据模型与物理数据模型比较 数据模型物理数据模型 包含内容体、属性表、字段 定位主主索引 使用名称 名称物理名称（受限于DBMS） 正化3NF 建可能会按照性能、空要求行非正化 冗余数据无冗余数据含冗余数据 派生数据无派生数据包含派生数据 开人 人与建模人物理数据 人 10 逻辑数据模型在数据仓库中的定位 存储 和管理 采集 回答 业务问题 析取 清洗 条件 剔除家庭关系 加载 业务系统 业务系统 业务数据 外部数据 关系数据库管理系统 聚集 统计 人工智能 神经网络 多维 可视化 EIS/DSS 电子表 对象语言 开发 企业 数据仓库 从属数据集市 业务人员 IT 用户 数据导入 知识发现 数据挖掘 信息存取 工具 源数据 逻辑数据模型 应用数据模型 11 内容安排 数据模型相关术语 什么是数据模型 建模注意事项 数据模型方法论 12 逻辑数据模型基本术语 (一) 模型结构 q第三范式（3NF）结构 q星型结构（多星型结构） q雪花型结构 模型分类 q概念数据模型 q逻辑数据模型 q物理数据模型 q应用数据模型 3NF 基础数据模型 Star Schema 汇总数据/已知应 用模型 Snowflake 星型结构的演变 13 实体 q独立型实体 q依赖型实体 q子类实体 q主题域 q层面 q核心实体 q关系实体 q特征实体 q分类实体 逻辑数据模型基本术语 (二) 14 属性： （描述真实或抽象事物相关联的特征或性质） q主键（识别实体实例唯一性的属性、属性组） q可选键 （能识别实体实例唯一性的其他属性、属性组） q外键（通过父实体到子实体关系转移到子实体的属性） q非键属性（不是实体主键属性的其他属性 ） q基础名（外键的原来名称 ） q角色名 （外键的新名称，表明取值是父实体属性的子集 ） q鉴别器 （取值决定父实体实例属于哪个子类的属性 ） 逻辑数据模型基本术语 (三) 15 关系 q二元关系 父实体的一个实例严格关系子实体的0，1或多个实例的这种 关系是二元关系 q基数 父、子实体实例的比例，如1：1，1：M q识别（型）关系 子实体实例唯一性的识别与父实体相关联，父实体的主键属 性成为子实体的主键属性 q非识别（型）关系 子实体不需要与父实体的关系就可以确定实例唯一性,父实体 的主键属性成为子实体的非键属性 逻辑数据模型基本术语 (四) 16 关系 q确定关系 父实体的一个实例对应子实体的0、1或多个实例，并且子实体 的一个实例对应0或1个父实体的实例 q非确定关系 多对多关系 q子类关系 子类实体和所属父实体的关系 q完全子类群 所属父实体的每个实例都能够与子类群的一个实体实例相关联 q不完全子类群 所属父实体的每个实例不一定都有子类相关联 逻辑数据模型基本术语 (五) 17 •Logical Data Model (LDM) •Example Entity Key Attribute Nonkey Attribute Relationship Cardinality One-to-many 1 : M Business Rule : • one customer invoice at least contains one invoice item 逻辑数据模型基本术语 (示例) 18 范式理论 Normal Form •关系数据库:原子性 •第一范式： • 每个属性的值唯一 •第二范式：键值依赖 非键属性依赖所有的主键属性。（不 存在部分键属性就决定的非键属性） •第三范式:完全键值依赖 非键属性完全依赖且只依赖与键属 性。（不存在非主键属性依赖其他非主 键属性的情况） •BCNF •第四范式 •第五范式 关系数据库理论中对于实体划分、实例（记录）设计的规则 The KEY - 1st Normal Form (1NF) The WHOLE Key - Second Normal Form (2NF) And NOTHING BUT the Key - Third Normal Form (3NF) -- E. F. Codd 19 违反第一范式 如果数Quantity属性被定义为“不是与Order相关，就是与Part相关” 例如：在OLTP系统中常见的字段复用现象，属此类问题 110 152 20 违反第二范式 依赖了复合主键的一部分 客户经理/地域 客户经理编号 21 违反第三范式 依赖了非主键属性（不参与主键的外键属性） 22 正则化LDM对数据库物理实现的优势 • 保留了更多的业务关系 • 更多的主索引选择 • 最佳的数据分布 • 更少的全表扫描 • 更多的连接选择 • 增强优化器使用更有利于提高性能的合并、聚合连接方法 • 最佳的数据分离（耦合度） • 最佳的底层模型与用户分离 • 最佳的数据控制 • 每行更少的字段 • 最佳的与应用分离 • 更小的行 • 最佳的数据块大小 • 减少临时与永久日志空间 • 减少物理 I/O 要考虑正则化对数据库性能的要求 23 内容安排 数据模型相关术语 什么是数据模型 建模注意事项 数据模型方法论 24 NCR数据仓库实施方法论 ? 规划 解决方案支持 数据仓库管理 (处理流程与操作) 物理数据库 设计 数据转换 应用开发 数据挖掘 服务 设计与实现支持与增强 解 决 方 案 体 系 结 构 设 计 元 数 据 管 理 数 据 仓 库 评 估 应用增强 逻辑数据 模型回顾 物理数据 库回顾 性能调整 容量规划 解 决 方 案 集 成 定制解决方案规划 详 细 数 据 分 析 解 决 方 案 准 备 就 绪 解 决 方 案 实 施 建 议 现成解决方案规划 数 据 仓 库 策 略 开 发 业务 探索 业务 探索 解决 方案 定义 逻辑 数据 模型 设计 修改 逻辑 数据 模型 验证 解决 方案 数据仓库的循环过程 25 逻辑数据模型设计步骤 Step 1: 定义业务需求与范围 Step 2: 定义实体 Step 3: 定义关系 Step 4: 定义非键属性 Step 5: 确认模型 26 Step 1: 定义业务需求与范围 1.确认已经理解全部业务需求 •什么困难或问题需要解决？一般情况下这些问题主要关 系到增加收入或降低成本等 •模型必须能够回答哪些业务问题？ •有哪些业务功能必须处理？ •有哪些业务限制存在？ •是否每一个参与人员都可以共享他们的业务需求？ 2.决定搜集需求的方法 •回顾已经存在的资料（例如现存的报表） •新的业务需求访谈 •以上两种混合的方法 27 Step 2: 定义实体 1.制定初始的实体池（不加区分的实体集合） 2.为每一个实体进行定义 3.删除超出项目范围的实体 4.为剩下的每一个实体定义主键 5.为可用的实体编写文档 •可选: 使用带样本数据的表格形式与用户进行确认 •必须: 使用ER图制定最终版本的交付材料 28 Step 3: 定义关系 1.识别实体间的关系 2.对于每一个关系 •删除超出项目范围的关系 •删除间接的关系 •为每一个剩余的关系进行定义 •识别每一个可用的关系的基数 (1:1, 1:M, M:M) 3.参照完整性 •确保每一个关系（PK/FK参照）是完整的、有效的 4.为模型中可用的关系编写文档，使用FK定义关系 •可选: 使用带样本数据的表格形式与用户进行确认 •必须: 使用ER图制定最终版本的交付材料 29 Step 4: 定义非键属性 1.识别并定义相关的非键属性 2.删除超出项目范围的属性 3.根据直觉或经验将剩余的可用属性放入一个表中 4.逐一验证每一个可用属性的摆放位置 5.为模型中的每一个可用属性编写文档 •可选: 使用带样本数据的表格形式与用户进行确认 •必须: 使用ER图制定最终版本的交付材料 6.在模型的最终交付文档中添加业务限制条件 30 Step 5: 确认模型 (1) 根据需要重复以上步骤 1.多次反复经常是必须的（需求、业务规则、操作的复杂性决定） 2.模型中的任何变更都会带来连锁反应，因此需要非常认真的回顾 与评审： •实体的变更经常影响关系的定义和属性的位置摆放 •关系的变更经常影响属性的位置摆放 •属性的位置的变更可能影响其他属性的摆放 31 Step 5: 确认模型 (2) 1.通过回答以下问题，持续地对模型的范围进行验证: •这一模型组件的含义、与业务的关系是什么？ •这一模型组件驱动的业务需求是什么？ 2.对模型是否已经满足所有业务需求、业务问题及限制条件等，进行验证 3.绝对不要考虑任何与物理实施相关的问题！ 4.当所有回答业务需求所必须的数据已经齐备时，停止对模型进行优化 32 主要任务： 转换逻辑数据模型（LDM）为物理数据模 型 定义主索引、次索引 非正规化处理（demoralizations） 数据库建立 设计优化 数据库功能测试 使用工具： ERWin 交付项目： 物理数据模型（PDM） 《物理数据模型说明书》 《数据库描述语言DDL》 物理数据库设计 数据仓库管理 物理数据 模型 数据转换 应用开发 数据挖掘 服务 系 统 体 系 结 构 设 计 元 数 据 管 理 解 决 方 案 集 成 33 物理数据模型命名规范 序 号 主 写 中文 1 PARTY PA R 参与人 2 OFFER OF R 品策 划 3 FINANCEFIN 4 LOCATION LO C 地理区 域 5 ADVERTISE MENT AD T 市 6 EVENTEVT 事件 7 NETWORK NE T 网 源 8 REFERENCE CODE CD E 代表 34 内容安排 数据模型相关术语 什么是数据模型 建模注意事项 数据模型方法论 35 建模注意事项 划分相应的主题 (客户、产品、账户、事件、行销活动、渠道、地理 区域) 确定主题与主题之间的关系 客户购买产品产生账户、使用产品触发事件 运营商通过各种渠道、在不同地理区域进行个性化的行销 活动 确定每个主题中关键的实体和实体间的关系 客户主题中：如参与人、个人、组织等实体、以及实体间 的关 系，参与人由个人和组织组成 进入逻辑数据模型，细化概念数据模型设计 36 建模注意事项 定义数据模型的命名规则 命名规范意义 统一命名，减少歧义 防止冗余的实体或属性的产生 良好的命名规范有助于业务人员与技术人员间的沟通 便于使用 逻辑模型实体和属性命名方法 实体名：PAR_Party：主题域大写＋实体描述词采用 全称 属性名：Account Nbr：词采用全称，首字母大写， 词与词 之间使用空格连接 37 LDM与PDM的区别 逻辑数据模型 (LDM) 内容 •业务模型 •记录业务规则和关系， •与数据库无关 用途： •与业务人员进行沟通和理解的工具 •用来确认可以回答业务问题 物理数据模型 (PDM) 内容 •数据库模型 •表现物理数据属性– 数据类型, 长度, 索引 •与数据库相关 用途： •支持业务系统运行 •解决数据存储问题 •解决应用处理性能问题 38 LDM实现为PDM的条件 LDM 业务规则 PDM 软、硬件 平台特性 应用开发策略 进行PDM设计必须考虑的因素、缺一不可： 核心业务规则 软、硬件平台个性化 用户、开发商个性化 70% 10% 20% 主要考虑因素输入内容影响程度 39 LDM 业务规则 PDM 业务规则继承 •PDM不应违反LDM中界定的业务规则 •包括： •业务概念相同 •业务关系相同 •核心业务要素相同 LDM－>PDM 40 业务规则继承（举例 ） 客户编码 A B C … 用户编码 客户编码 X Y … 业务规则： •客户的定义是XXX（实体定义） •鉴别客户唯一性的标识为客户编码（主键） •客户核心属性包括:A，B，C…（属性） •一个客户可以拥有多个用户（关系） •识别用户所属客户的标识为客户编码（外键） 客户用户 CUST_ID A B C … USER_ID CUST_ID X Y … CUSTUSER 41 软、硬件 平台特性 考虑平台特色 •PDM应考虑实际数据库平台的特色 •包括： •不同数据库的数据类型、长度不同 •不同数据库的索引机制不同 •不同的数据库处理性能不同 •不同的硬件平台、配置处理性能不同 PDM LDM－>PDM 42 考虑平台特色（举例 ） 客户编码 客户姓名 B C … 用户编码 客户编码 X Y … 客户用户 CUST_ID Char（8） Cust _Name Char（8） B C … USER_ID CUST_ID X Y … CUSTUSER Cust_ID Longint Guest_Name Char （12） B C … USER_ID CUST_ID X Y … CUSTUSER 例如：数据类型、长度不同等 43 应用开发策略 考虑应用开发策略 •PDM应考虑应用系统的实施策略 •包括： •表的横向分割； •表的纵向分割； •创建汇总表、临时表； •属性冗余； •创建主索引（可能与LDM主键不同）； PDM LDM－>PDM 44 考虑应用开发策略（举例 ） 客户编码 客户姓名 B C … 用户编码 客户编码 X Y … 客户用户 CUST_ID Cust _Name B USER_ID CUST_ID X Y … CUST_BUSER CUST_ID C CUST_C 横向分表 CUST_ID A B C … USER_ID CUST_ID X Y A CUST 1USER CUST_ID A B C … CUST 2 CUST_ID A B C … CUST 3 … 1类 （前1000条） 2类 （中2000条） 3类 （后1000条） 共3000条 例如：横向表、纵 向分表、子类、属 性冗余等 45 建模注意事项 设计逻辑数据模型 按照ERA设计流程设计逻辑数据模型 确定实体Entity 定义实体的主键KEY 定义部分非键属性Non-Key Attribute 定义非唯一属性组，Inversion Entry 添加相应的注释内容 46 建模注意事项 设计逻辑数据模型 确定实体与实体之间的关系Relationship 确定实体间关系属于1:1，1：M还是M:M 通过Foreign Key进行体现 补充实体的非键值属性Attribute 按照3NF的规则，判定每添加的一个属性是否符 合3NF的设计原则 增加的属性如果违反3NF，确定新的实体和关系 添加中文注释部分 47 建模注意事项 物理数据模型设计 物理数据模型的输入 逻辑数据模型 SDA源数据分析 非正则化方面的需求，如性能和存储的要求 物理数据模型的输出 物理数据模型 物理数据模型设计说明书 生成DDL建表语句 作为SDM（源数据对应）的输入，SDM将提供ETL数据转换规则 48 建模注意事项 物理数据模型设计 以逻辑数据模型作为输入 按照RDBMS的要求对于相应的表和字段进行简写 依照物理数据模型命名规范 非正则化处理 定义索引 定义是否允许NULL 定义是否可以压缩 定义是否大小写敏感 定义是否需要分区 49 模型设计的后续工作 模型的验证工作 软验证－业务案例 硬验证－业务数据 模型设计维护和扩展工作 数据模型是不断增强的，可扩展的，但要保证其相对的稳 定性 前端应用中的多维模型的设计 前端应用以及ETL从性能和使用上对于PDM的修改要求 业务规则的变化以及新的产品的产生也会对LDM和PDM有 修改或者扩展的要求 模型设计要考虑今后的可扩展性，以适应新的业务规则和 业务需求。 50 51 ℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡2.1.2 2.1.2 需求工程过程需求工程过程 问题识别 分析与综合 编写文档 分析评审 2.1.2 需求分析过程 可行性研究 需求导出 和分析 需求描述 需求有效性 验证 可行性报告 系统模型 用户需求和 系统需求 需求文挡 结构化开发方法结构化开发方法（（Structured Developing MethodStructured Developing Method）） 是现有的软件开发方法中最成熟，应用最广泛的方法，主要 特点是快速，自然和方便。 结构化方法总的指导思想自顶向下、逐步求精。它的基本原 则是功能的分解与抽象。 2.2 2.2 结构化分析方法结构化分析方法 结构化开发方法的组成 70年代初 结构化程序设计方法 SP法（Structured Program ） 70年代中 结构化设计方法 SD法（Structured Design） 70年代末 结构化分析方法 SA法（Structured Analysis） SA，SD，SP 法相互衔接，形成了一整套开发方法。若将 SA，SD 法结合起来，又称为结构化分析与设计技术（ SADT 技术）。 2.2.1 SA2.2.1 SA法概述法概述 分解：对于一个复杂的系统， 为了将复杂性降低到可以掌握的 程度，可以把大问题分解成若干 小问题，然后分别解决（如右图 ）。 一、一、SASA法的基本思想法的基本思想 结构化分析方法的基本思想是“分解”和“抽象”。 抽象：分解可以分层进行，即先考虑问题最本质的属性， 暂把细节略去,以后再逐层添加细节，直至涉及到最详细的 内容，这种用最本质的属性表示一个系统的方法就是“抽象” 。 2.2.1 SA法的概述 1.1 1.21.3 x 2 13 2.1 2.2 2.3 1.1 1.3 1、建立当前系统的“具体模型”。 基本思想与步骤 三、三、SASA法的描述方法法的描述方法 1、分层的数据流图 2、数据词典 3、描述加工逻辑的结构化语言、判定表及判定树 2.2.1 SA法的概念 二、二、SASA法的步骤法的步骤 4、为了对目标系统做完整的描述，还需要考虑人机界面和 其他一些问题。 3、建立目标系统的逻辑模型。 2、抽象出当前系统的逻辑模型。 顾客 出版社 验证 订单 汇总 订单 订单 出版社 订单 图书目录文件 顾客档案 待处理订单文件 正确 订单 一批 订单 出版社档案文件 订货存根文件 DFD图的例子 加工名 编号 加工名 编号 文件名 文件名 顾客 出版社 验证 订单 汇总 订单 订单 出版社 订单 图书目录文件 顾客档案 待处理订单文件 正确 订单 一批 订单 出版社档案文件 订货存根文件 画图步骤 ： 1、确定外部实体及输入、输出数据流。 2、确定分解顶层的加工。 3、确定使用的文件。 4、用数据流将各部分连接起来，形成数据封闭。 注意：标注各加工框及数据流名称。 例1：图书预定系统（顶层DFD图） 2.2.2 2.2.2 数据流图数据流图 数据流图（Data Flow Diagram，DFD）是描述系统中数据流程 的图形工具，它标识了一个系统的逻辑输入和逻辑输出，以及把逻 辑输入转换为逻辑输出所需的加工处理。 数据存储 数据源点 或终点 加 工加工名 数据流 数据流名 文件名 实体名 箭 头 圆或椭圆 单或双杠 矩形框 还有一些辅助的图例: 2.2.2 分层的数据流图 一、数据流图的图符 四种基本图形符号： T A B * C T A B * C T A B + C T A B + C T A B C + T A B C + * 与 + 或互斥+ “先全局后局部,先整体后细节,先抽象后具体” 通常可将这种分层的DFD图,分为顶层、中间层、底层。 具体步骤： 1。先确定系统范围，画出顶层的DFD图。 2。逐层分解顶层DFD图，获得若干中间层DFD图。 3。画出底层的DFD图。 2.2.3 画分层DFD图的方法 顶层图说明了系统的边界,即系统的输入和输出数据 流，顶层图只有一张。底层图由一些不能再分解的加工 组成，这些加工都已足够简单，称为基本加工。在顶层 和底层之间的是中间层。中间层的数据流图描述了某个 加工的分解，而它的组成部分又要进一步分解。 画各层DFD图时，“由外向内”。 X 1 3 2 1.1 1.2 1.4 1.3 2.1 2.2 1.1.1 1.1.2 2.1.3 2.1.2 2.1.12.2.2 2.2.3 2.2.1 顶 层 中 间 层 底 层 先全局后局部, 先整体后细节, 先抽象后具体. 0图 1图 2图 1.1图 2.1图 2.2图 分层 DFD 图 经过初步的需求分析，得到系统功能要求： 1、监视病员的病症（血压、体温、脉搏等）。 2、定时更新病历。 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。 2.2.4 实例：医院病房监护系统 产生 病情报告 监视病情 更新病历 2.2.4 实例：医院病房监护系统 系统功能要求： 1、监视病员的病症（血压、体温、脉搏等） 2、定时更新病历 3、病员出现异常情况时报警。 4、随机地产生某一病员的病情报告。 顶层 ： 病员 护士 护士 病员监 护系统 病员日志 病症信号 要求报告 病症报告 报警 例2 医院病房监护系统 第一层： 病员 护士 护士 中央监视 病员日志 病症信号 要求报告 病症报告 报警 局部监视 生成报告 病员极限 更新日志 病员数据 格式化 病员数据 生理信号 极限值 1 3 2 4 日志数据 日志数据 医院病房监护系统顶层DFD图 第二层：加工“中央监视”分解 计算超过 极限值否 病员数据 超过极限值 报警 开解信号 产生 报警信息 病员极限 格式化 病员数据 体温 血压、体温 脉搏 生理信号 极限值 时间 脉搏 血压 日期 时钟 格式化 病员数据 3.1 3.2 3.33.4 医院病房监护系统二层DFD图 计算超过 极限值否 病员数据 超过极限值 报警 开解信号 产生 报警信息 病员极限 格式化 病员数据 体温 血压、体温、 脉搏 生理信号 极限值 时间 脉搏 血压 日期 时钟 格式化 病员数据 3.1 3.2 3.3 3.4 第二层：加工“中央监视”分解 医院病房监护系统分层医院病房监护系统分层DFDDFD图图 图 2..15 第一层 格式化 病员数据 生理信号 极限值 病员 护士 护士 中央监视 病员日志 病症信号 要求报告 病症报告 报警 局部监视 生成报告 病员极限 更新日志 病员 数据 1 3 2 4 日志数据 图 2..16 加工分解的原则 自然性：概念上合理、清晰； 均匀性：理想的分解是将一个问题分解成大小均匀的几 个部分； 分解度：一般每一个加工每次分解最多不要超过７个子 加工,分解应分解到基本加工为止。 2.2.5 2.2.5 画分层画分层DFDDFD图的基本原则图的基本原则 数据守恒与数据封闭原则 所谓数据守恒是指加工的输入输出数据流是否匹配， 即每一个加工既有输入数据流又有输出数据流。或者说一 个加工至少有一个输入数据流，一个输出数据流。 数据封闭是对整个系统而言。 合理使用文件 当文件作为某些加工之间的交界面时，文件必须画 出来，一旦文件作为数据流图中的一个独立成份画出来 了，那么他同其他成份之间的联系也应同时表达出来。 DFD图不是流程图,不表示软件的控制流程。 2.2.5 2.2.5 画分层画分层DFDDFD图的基本原则图的基本原则 子图与父图的“平衡” 父图中某个加工的输入输出数据流应该同相应的子 图的输入输出相同(相对应），分层数据流图的这种特 点称为子图与父图“平衡”。 2.2.6 分层DFD图的改进 DFD图必须经过反复修改，才能获得最终的目标系统的 逻辑模型（目标系统的DFD图）。可从以下方面考虑DFD图 的改进： 1、检查数据流的正确性 ① 数据守恒 ② 子图、父图的平衡 ③ 文件使用是否合理。特别注意输入/出文件的数据流。 2、改进DFD图的易理解性 ① 简化加工之间的联系（加工间的数据流越少，独立性越 强，易理解性越好）。 ② 改进分解的均匀性。 ③ 适当命名（各成分名称无二义性，准确、具体）。 结构化语言是介于自然语言和形式语言之间的一种半形 式语言，它是自然语言的一个受限制的子集。一般分为两层 结构：外层语法较具体，为控制结构（顺序、选择、循环）, 内层较灵活，表达“做什么”。 一、一、 结构化语言结构化语言 例如：外层可为以下结构： 1、顺序结构 2、选择结构 IF–THEN-ELSE; CASE-OF-ENDCASE； 3、循环结构 WHILE-DO; REPEAT-UNTIL 构造原型 运行/评价原型 原型完成否 要细部说明否 严格说明细部 效果满意否 整理原型提供文档 修 正 改 进 原 型 Y Y N N 快速分析，确定初步规格说明 Y N 快速原型化开发过程 2.3.2 快速原型开发模型 快速建立系统原型进行系统的 分析和构造有如下优点： 1、增进软件开发人员和用户 对系统需求的理解。便于将用户 模糊的功能需求明确化。 2、为用户提供了一种强有力 的学习手段。 3、易于确定系统的性能，是 理解和确认软件需求规格说明的 工具。 4、按照RCP 法建立的原型即 为最终的产品。 细化的原型化模型 需求工程小结需求工程小结 需求工程小结 最初，需求工程仅仅是软件工程的一个组成部分，是软件最初，需求工程仅仅是软件工程的一个组成部分，是软件 生命周期的第一个阶段。 生命周期的第一个阶段。 在传统软件工程生命周期中，涉及需求的阶段称作需求分在传统软件工程生命周期中，涉及需求的阶段称作需求分 析。一般来说，需求分析的作用是：析。一般来说，需求分析的作用是： ● ● 系统工程师说明软件的功能和性能，指明软件和其他系系统工程师说明软件的功能和性能，指明软件和其他系 统成分的接口，并定义软件必须满足的约束；统成分的接口，并定义软件必须满足的约束； ● ● 软件工程师求精软件的配置，建立数据模型、功能模型软件工程师求精软件的配置，建立数据模型、功能模型 和行为模型；和行为模型； ● ● 为软件设计者提供可用于转换为数据设计、体系结构设为软件设计者提供可用于转换为数据设计、体系结构设 计、界面设计和过程设计的模型；计、界面设计和过程设计的模型； ● ● 提供开发人员和客户需求规格说明，用于作为评估软件提供开发人员和客户需求规格说明，用于作为评估软件 质量的依据。质量的依据。 需求工程小结需求工程小结 需求工程是系统工程和软件工程的一个交叉分支，涉及到 软件系统的目标、软件系统提供的服务、软件系统的约束和软 件系统运行的环境。它还涉及这些因素和系统的精确规格说明 以及系统进化之间的关系。它也提供现实需要和软件能力之间 的桥梁。 需求工程的基本活动包括：需求工程的基本活动包括： ● 抽取需求； ● 模拟和分析需求； ● 传递需求； ● 认可需求； ● 进化需求。 ᅰ ᅰ 、活动流量和常规搜索流量。卡位 就是去卡搜索流量。 卖家利用淘词搜索关键词“珍珠”，复 制搜索次数排名前100的词组，这时候的每 个词都是一条街道，有自己的流量和转化率 ，首先要做的就是选定在哪条“街道”里铺 货。选完一个词后，放在淘宝主搜索栏内查 看，要查看的内容包括宝贝排序等。如“珍 珠项链”一词，按“人气”排序，结果如图 4所示。 25 数据魔方价值 （2）利用选词做卡位 接着，要查看排名前列店铺的细节，包 括店铺评分、价格、销量、店铺类型，衡量 与竞争对手拼爆款的能力。例如查看“珍珠 项链”词条下大部分在售宝贝的类型，然后 选择同类型宝贝做推广；同时对比自己店铺 商品跟竞品的价格，用价格战去卡位。 当然，我们不提倡一味地价格战，因此 卖家就要研究如何增加自身的产品附加值， 通过搭配捆绑销售，让产品价值超过竞争对 手的宝贝； 通过这些要素的衡量，选词已不是简单 的优化标题，而深化为竞品分析。除此之外 ，我们也要实时关注淘宝的搜索变化，词汇 搜索的不稳定性非常大。比如“奥运会”时 间段，相关关键词是否会有突增的趋势？消 费者远比我们想象的要敏感。 26 数据魔方价值 （3）直通车如何投放 优化标题有一套成熟的归纳方法。针对 宝贝的不同销量，有三种选词方式，销量低 和销量高的宝贝做直通车营销要区别对待。 针对销量低的宝贝，一般情况下并不推荐做 主动营销推广。因此销量低的宝贝推广需要 另辟蹊径的玩法，如长尾词的直通车投放， 竞争少竞价低，同时长 尾词可以引来较精准的 流量，尽可能增大现。 27 数据魔方价值 （3）直通车如何投放 做销量较高的宝贝直通车，简单的原则 就是“精准匹配”。用最合适的热词去匹配 宝贝，让宝贝的展现尽可能最大化。比如宝 贝本身积累了一定销量，同时宝贝评价和店 铺信誉都不错，此时就需要用直通车“精准 匹配”的方式去投放。根据宝贝发布后台选 择的类目属性一一匹配，通过积累养好这个 词，这个方法得到淘宝很多“开车”高手的 验证，百试不爽。 同时，大家在选择直通车推广时，要把 握即时的讯息，如淘词的“行业热词榜”里 的“飙升热词榜”经常被大多数卖家遗漏， 其实这也是非常关键的“开车”参考。 28 数据魔方价值 （3）直通车如何投放 比如“连衣裙”类目飙升前三位的词都 是跟“秋季”相关，我们点击其中的一个词 查看具体数据，如图10所示，继续按照以上 讲述的卡位方法筛选词。 同时我们可以观察某个关键词如“秋装 连衣裙”的点击次数趋势图和子类目分布趋 势图（图11和12），可以看到消费者的点击 有一个爆发性增长的过程。单纯地看某一个 词的搜索飙升，无法体现出消费者的关注度 在时间维度的扩展，只有在消费者点击增长 阶段去投放直通车，才会获得比较高的转化 率。 29 数据魔方价值 （3）直通车如何投放 继续查看该热词的子行业分布排行，就 可以定位“秋装连衣裙”搜索人群涉及的主 要类目，方便在投放前去做参考。 直通车的定向投放也是可以考虑的方 法。如今的直通车后台，增加了针对地域人 群分布的数据，同时结合数据魔方里的消费 者地域分布（图13），我们可以做定向的直 通车投放，营销精准化。 针对不同省份、城市的人群做定向的投 放，根据需求去做供应链管理，这样的营销 才是科学的。 30 意见与建议 3 3 3 3 31 l添加收藏数据（如：购买顾客收藏数 、没有购买顾客收藏数） 每天收藏量变化我们可以通过量子恒道获取，但这一部分数每天收藏量变化我们可以通过量子恒道获取，但这一部分数 据中，已购买顾客的收藏是多少据中，已购买顾客的收藏是多少 ，哪些又是喜欢此商品但并没有，哪些又是喜欢此商品但并没有 在当天发生购买的顾客，避免我们盲目认为当天没有购买就是不在当天发生购买的顾客，避免我们盲目认为当天没有购买就是不 需要或不喜欢我们店铺宝贝，相信也能有助我们更精准分析流失需要或不喜欢我们店铺宝贝，相信也能有助我们更精准分析流失 的顾客的顾客 。。 意见与建议 32 谢谢 THANKS 彭彧 2013/4/11 33 ℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡℡
展开阅读全文
相关搜索
资源标签
