文档详情

数据模型基本概念与建模方法论_logic

s9****2
实名认证
店铺
PPT
6.11MB
约52页
文档ID:567660055
数据模型基本概念与建模方法论_logic_第1页
1/52

数据模型的基本概念及建模方法论 ü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 逻辑数据模型在数据仓库中的定位ü11存储和管理采集回答业务问题 析取 清洗 条件 剔除家庭关系 加载 业务系统 业务系统 业务数据 外部数据 关系数据库管理系统聚集 统计 人工智能 神经网络 多维 可视化 EIS/DSS 电子表 对象语言 开发 企业 数据仓库 从属数据集市 业务人员 IT 用户数据导入 知识发现 数据挖掘 信息存取 工具源数据 逻辑数据模型应用数据模型 ü12内容安排è数据模型相关术语è 什么是数据模型è建模注意事项è 数据模型方法论 ü13逻辑数据模型基本术语 (一) 模型结构模型结构 q第三范式(第三范式(3NF))结构结构 q星型结构(多星型结构)星型结构(多星型结构)q雪花型结构雪花型结构 模型分类模型分类q概念数据模型概念数据模型q逻辑数据模型逻辑数据模型q物理数据模型物理数据模型q应用数据模型应用数据模型3NF基础数据模型Star Schema汇总数据/已知应用模型Snowflake星型结构的演变 ü14实体实体 q独立型实体独立型实体 q依赖型实体依赖型实体 q子类实体子类实体 q主题域主题域q层面层面q核心实体核心实体 q关系实体关系实体 q特征实体特征实体q分类实体分类实体逻辑数据模型基本术语 (二) ü15属性:属性: (描述真实或抽象事物相关联的特征或性质) q主键主键(识别实体实例唯一性的属性、属性组) q可选键可选键 (能识别实体实例唯一性的其他属性、属性组)q外键外键(通过父实体到子实体关系转移到子实体的属性)q非键属性非键属性(不是实体主键属性的其他属性 ) q基础名基础名(外键的原来名称 )q角色名角色名 (外键的新名称,表明取值是父实体属性的子集 )q鉴别器鉴别器 (取值决定父实体实例属于哪个子类的属性 )逻辑数据模型基本术语 (三) ü16关系关系q二元关系二元关系父实体的一个实例严格关系子实体的0,1或多个实例的这种关系是二元关系 q基数基数父、子实体实例的比例,如1:1,1:Mq识别(型)关系识别(型)关系子实体实例唯一性的识别与父实体相关联,父实体的主键属性成为子实体的主键属性 q非识别(型)关系非识别(型)关系子实体不需要与父实体的关系就可以确定实例唯一性,父实体的主键属性成为子实体的非键属性 逻辑数据模型基本术语 (四) ü17关系关系q确定关系确定关系父实体的一个实例对应子实体的0、1或多个实例,并且子实体的一个实例对应0或1个父实体的实例 q非确定关系非确定关系多对多关系 q子类关系子类关系子类实体和所属父实体的关系 q完全子类群完全子类群所属父实体的每个实例都能够与子类群的一个实体实例相关联 q不完全子类群不完全子类群所属父实体的每个实例不一定都有子类相关联 逻辑数据模型基本术语 (五) Logical Data Model (LDM) Exampleü18 EntityKey AttributeNonkey AttributeRelationshipCardinalityOne-to-many1 : MBusiness Rule :• one customer invoice at least contains one invoice item逻辑数据模型基本术语 (示例) 范式理论 NORMAL FORM关系数据库:原子性第一范式: 每个属性的值唯一第二范式:键值依赖 非键属性依赖所有的主键属性。

不存在部分键属性就决定的非键属性)第三范式:完全键值依赖 非键属性完全依赖且只依赖与键属性不存在非主键属性依赖其他非主键属性的情况)BCNF第四范式第五范式ü19关系数据库理论中对于实体划分、实例(记录)设计的规则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 违反第一范式ü20如果数Quantity属性被定义为“不是与Order相关,就是与Part相关”例如:在OLTP系统中常见的字段复用现象,属此类问题110152 违反第二范式ü21依赖了复合主键的一部分客户经理/地域客户经理编号 违反第三范式ü22依赖了非主键属性(不参与主键的外键属性) 正则化LDM对数据库物理实现的优势￿保留了更多的业务关系 更多的主索引选择 最佳的数据分布 更少的全表扫描￿更多的连接选择￿增强优化器使用更有利于提高性能的合并、聚合连接方法 最佳的数据分离(耦合度) 最佳的底层模型与用户分离 最佳的数据控制 每行更少的字段 最佳的与应用分离 更小的行 最佳的数据块大小 减少临时与永久日志空间￿减少物理￿I/Oü23要考虑正则化对数据库性能的要求 ü24内容安排è数据模型相关术语è 什么是数据模型è建模注意事项è 数据模型方法论 NCR数据数据仓库实施方法施方法论ü25?规划规划解决方案支持数据仓库管理(处理流程与操作)物理数据库设计数据转换应用开发数据挖掘服务设计与实现设计与实现支持与增强支持与增强解决方案体系结构设计元数据管理数据仓库评估应用增强逻辑数据模型回顾物理数据库回顾性能调整容量规划解决方案集成定制解决方案规划详细数据分析解决方案准备就绪解解决决方方案案实实施施建建议议现成解决方案规划数数据据仓仓库库策策略略开开发发业务探索业务探索解决方案定义逻辑数据模型设计修改逻辑数据模型验证解决方案数据仓库的循环过程 逻辑数据模型设计步骤ü26Step 1: 定义业务需求与范围Step 2: 定义实体Step 3: 定义关系Step 4: 定义非键属性Step 5: 确认模型 STEP 1: 定义业务需求与范围ü271.确认已经理解全部业务需求•什么困难或问题需要解决?一般情况下这些问题主要关系到增加收入或降低成本等•模型必须能够回答哪些业务问题?•有哪些业务功能必须处理?•有哪些业务限制存在?•是否每一个参与人员都可以共享他们的业务需求?2.决定搜集需求的方法•回顾已经存在的资料(例如现存的报表)•新的业务需求访谈•以上两种混合的方法 STEP 2: 定义实体ü281.制定初始的实体池(不加区分的实体集合)2.为每一个实体进行定义3.删除超出项目范围的实体4.为剩下的每一个实体定义主键5.为可用的实体编写文档•可选: 使用带样本数据的表格形式与用户进行确认•必须: 使用ER图制定最终版本的交付材料 STEP 3: 定义关系ü291.识别实体间的关系2.对于每一个关系•删除超出项目范围的关系•删除间接的关系•为每一个剩余的关系进行定义•识别每一个可用的关系的基数 (1:1, 1:M, M:M)3.参照完整性•确保每一个关系(PK/FK参照)是完整的、有效的4.为模型中可用的关系编写文档,使用FK定义关系•可选: 使用带样本数据的表格形式与用户进行确认•必须: 使用ER图制定最终版本的交付材料 STEP 4: 定义非键属性ü301.识别并定义相关的非键属性2.删除超出项目范围的属性3.根据直觉或经验将剩余的可用属性放入一个表中4.逐一验证每一个可用属性的摆放位置5.为模型中的每一个可用属性编写文档•可选: 使用带样本数据的表格形式与用户进行确认•必须: 使用ER图制定最终版本的交付材料6.在模型的最终交付文档中添加业务限制条件 STEP 5: 确认模型 (1)ü31根据需要重复以上步骤1.多次反复经常是必须的(需求、业务规则、操作的复杂性决定)2.模型中的任何变更都会带来连锁反应,因此需要非常认真的回顾与评审:•实体的变更经常影响关系的定义和属性的位置摆放•关系的变更经常影响属性的位置摆放•属性的位置的变更可能影响其他属性的摆放 STEP 5: 确认模型 (2)ü321.通过回答以下问题,持续地对模型的范围进行验证: •这一模型组件的含义、与业务的关系是什么?•这一模型组件驱动的业务需求是什么?2.对模型是否已经满足所有业务需求、业务问题及限制条件等,进行验证3.3.绝对不要考虑任何与物理实施相关的问题!绝对不要考虑任何与物理实施相关的问题!4.当所有回答业务需求所必须的数据已经齐备时,停止对模型进行优化 主要任务:主要任务:Ø转换逻辑数据模型(转换逻辑数据模型(LDM)为物理数据模型)为物理数据模型Ø定义主索引、次索引定义主索引、次索引Ø非正规化处理(非正规化处理(demoralizations))Ø数据库建立数据库建立Ø设计优化Ø数据库功能测试使用工具:使用工具:ØERWin交付项目:交付项目:Ø 物理数据模型(物理数据模型(PDM))Ø《物理数据模型说明书》Ø《《数据库描述语言数据库描述语言DDL》》ü33物理数据库设计数据仓库管理物理数据模型数据转换应用开发数据挖掘服务系统体系结构设计元数据管理解决方案集成 物理数据模型命名规范 序号主题缩写中文1 PARTYPAR参与人2 OFFEROFR产品策划3 FINANCEFIN账务4 LOCATIONLOC地理区域5 ADVERTISEMENTADT市场营销6 EVENTEVT事件7 NETWORKNET网络资源8 REFERENCE CODECDE代码表ü34 ü35内容安排è数据模型相关术语è 什么是数据模型è建模注意事项è 数据模型方法论 建模注意事项划分相应的主题(客户、产品、账户、事件、行销活动、渠道、地理区域)Ø确定主题与主题之间的关系ü客户购买产品产生账户、使用产品触发事件ü运营商通过各种渠道、在不同地理区域进行个性化的行销活动Ø确定每个主题中关键的实体和实体间的关系确定每个主题中关键的实体和实体间的关系ü客户主题中:如参与人、个人、组织等实体、以及实体间的关 系,参与人由个人和组织组成Ø进入逻辑数据模型,细化概念数据模型设计ü36 建模注意事项定义数据模型的命名规则Ø命名规范意义ü统一命名,减少歧义统一命名,减少歧义ü防止冗余的实体或属性的产生防止冗余的实体或属性的产生ü良好的命名规范有助于业务人员与技术人员间的沟通ü便于使用 Ø逻辑模型实体和属性命名方法ü实体名:PAR_Party:主题域大写+实体描述词采用全称ü属性名:Account Nbr:词采用全称,首字母大写,词与词 之间使用空格连接ü37 ü38LDM与与PDM的区别的区别逻辑数据模型 (LDM)内容内容•业务模型业务模型•记录业务规则和关系记录业务规则和关系,•与数据库无关与数据库无关用途:用途:•与业务人员进行沟通和理解的工具与业务人员进行沟通和理解的工具•用来确认可以回答业务问题用来确认可以回答业务问题物理数据模型 (PDM)内容内容•数据库模型数据库模型•表现物理数据属性表现物理数据属性– 数据类型数据类型, 长度长度, 索引索引•与数据库相关与数据库相关用途:用途:•支持业务系统运行支持业务系统运行•解决数据存储问题解决数据存储问题•解决应用处理性能问题解决应用处理性能问题 ü39LDM实现为实现为PDM的条件的条件LDM业务规则业务规则PDM软、硬件软、硬件平台特性平台特性应用开发策略应用开发策略进行PDM设计必须考虑的因素、缺一不可:核心业务规则软、硬件平台个性化用户、开发商个性化70%10%20%主要考虑因素输入内容影响程度 ü40LDM业务规则业务规则PDM业务规则继承业务规则继承•PDM不应违反LDM中界定的业务规则•包括:•业务概念相同•业务关系相同•核心业务要素相同LDM-->PDM ü41业务规则继承(举例业务规则继承(举例 ))客户编码ABC…用户编码客户编码XY…业务规则:•客户的定义是XXX(实体定义)•鉴别客户唯一性的标识为客户编码(主键)•客户核心属性包括:A,B,C…(属性)•一个客户可以拥有多个用户(关系)•识别用户所属客户的标识为客户编码(外键)客户用户CUST_IDABC…USER_IDCUST_IDXY…CUSTUSER ü42软、硬件软、硬件平台特性平台特性考虑平台特色考虑平台特色•PDM应考虑实际数据库平台的特色•包括:•不同数据库的数据类型、长度不同•不同数据库的索引机制不同•不同的数据库处理性能不同•不同的硬件平台、配置处理性能不同PDMLDM-->PDM ü43考虑平台特色(举例考虑平台特色(举例 ))客户编码客户姓名BC…用户编码客户编码XY…客户用户CUST_ID  Char(8)Cust _Name Char(8)BC …USER_IDCUST_IDXY…CUSTUSERCust_ID  LongintGuest_Name Char (12)BC…USER_IDCUST_IDXY…CUSTUSER例如:数据类型、长度不同等 ü44应用开发策略应用开发策略考虑应用开发策略考虑应用开发策略•PDM应考虑应用系统的实施策略•包括:•表的横向分割;•表的纵向分割;•创建汇总表、临时表;•属性冗余;•创建主索引(可能与LDM主键不同);PDMLDM-->PDM ü45考虑应用开发策略(举例考虑应用开发策略(举例 ))客户编码客户姓名BC…用户编码客户编码XY…客户用户CUST_IDCust _NameBUSER_IDCUST_IDXY…CUST_BUSERCUST_IDCCUST_C横向分表CUST_IDABC…USER_IDCUST_IDXYACUST 1USERCUST_IDABC…CUST 2CUST_IDABC…CUST 3…1类(前1000条)2类(中2000条)3类(后1000条)共3000条例如:横向表、纵向分表、子类、属性冗余等 建模注意事项设计逻辑数据模型按照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 ü知识回顾知识回顾Knowledge Knowledge ReviewReview 谢￿ ￿谢! 放映结束 感谢各位的批评指导!让我们共同进步 。

下载提示
相似文档
正为您匹配相似的精品文档