企业数据模型设计方法论探讨
企业数据模型设计方法论探讨
企业级数据模型设计方法论探讨
1引言
数据模型设计是一个老生常谈的话题，在以往的数据仓库BI项目中，数据模型的方法论、概念通常大多围绕如何设计和建设数据仓库，而应用系统（OLTP 系统）模型设计却缺乏方法论的指导，加之各应用系统通常都是由不同厂商在不同时期自行设计开发，彼此之间缺乏沟通，导致数据分散重复、口径不一致和数据兼容性差。由于数据仓库在企业整体信息化规划中属于下游系统，只能被动接收由各应用系统产生的数据，数据入仓之后，由于口径不一致、兼容性差，给数据整合带来极大困难。企业在投入大量的人力、物力和资金推进信息化建设，仍然出现大量的“信息孤岛”现象。
本文认为，企业信息化建设的成功很大程度上取决于系统模型的合理性和不同系统间概念的一致性，而企业级数据模型是企业信息化的核心问题，通过企业级数据模型定义整个企业信息化体系的数据标准，逐步统一企业内部数据标准，指导各应用系统数据模型统一设计，可以从根本上保证系统之间数据的兼容性和一致性，消除由于各应用系统自行设计开发而导致的数据分散重复、口径不一致和信息孤岛现象，推动企业内各类应用系统的整合和数据的共享，全面提升经营决策、运营管理、业务拓展和客户服务等方面的支撑能力。
本文将首先阐述企业级数据模型的定义和结构，分析其业务价值。通过描述企业级数据模型与应用系统模型间关系，划分两者之间的概念边界和区别，从而更好的理解企业级数据模型的真正内涵。其次，阐述了企业级数据模型设计的基本方法和关键要点，使读者能够掌握企业级数据模型设计的整体思路，以便对后续工作提供借鉴和指导作用。最后，总结了多个项目的经验教训，分享企业级数据模型建模过程中的心得体会，希望对大家能有所帮助。
2企业级数据模型定义
2.1模型基本定义
企业级数据模型不能等同于数据仓库模型，企业级数据模型是站在整个企
业业务的视角，对企业全部数据（包括生产数据和消费数据）全貌性、整体性描述。企业级数据模型是业务人员和IT人员进行沟通的媒介、也是企业内部与外部进行交流的纽带。
企业级数据模型是一种建设蓝图，它识别了企业内部跨功能、跨部门、跨组织的共享或冗余数据，为系统的规划、设计和实施提供一种可视化方式和支撑框架，是企业内部所有应用系统数据模型设计的起点，如ODS、EDW等系统的设计开发，有助于促进数据整合、消除数据孤岛和遗留系统保持一致。
企业级数据模型是一个数据集成定义，它不依赖于企业内部某个具体的系统或应用，也跟数据的物理实现无关（包括数据如何获取、如何存储、如何处理以及如何访问）。
2.2模型结构
企业级数据模型可分解为三个层级：主题域模型、概念模型和逻辑模型。三个层次模型逐级扩展。企业级数据模型的创建更是一种艺术而非一门科学，应集中企业的集体智慧，共同推进企业级数据模型的不断完善。
2.2.1主题域模型
企业主题域模型在企业级数据模型中处于第一层次，其覆盖原则是“有需求才覆盖”，一个企业的平均主题域数量通常在10~20之间。
?主题域模型内涵
●主题（Subject）是在较高层次上将企业的数据进行综合、归类和分
●
●概念模型定义了企业内主要业务实体及实体间的业务关系。
●概念模型不描述业务实体的数据属性
●实体之间可能存在多对多关系，不对数据进行范式化处理。
2.2.3逻辑模型
企业逻辑模型在企业级数据模型中处于第三层次，并将每个概念进一步细分为“逻辑实体”。企业逻辑模型由逻辑实体、业务主键、关联关系和重要属性组成。
?逻辑模型特征
●逻辑模型是对概念模型的进一步分解和细化，通过关键数据属性描
述更多业务细节
●逻辑模型描述实体、属性以及实体关系
●逻辑模型只包含关键数据属性，而不是全部实体和全部属性。关键数
据属性是指那些如果缺失而导致企业无法正常运转的属性，但这种判
断通常是非常主观的决定。
●设计时一般遵从“第三范式”，以求达到最小的数据冗余，维护数据
的完整性和可扩展性检查数据模型是否符合第三范式要求，有如下
三条检验标准：
?主键是唯一的，不具有多义性。
?每个非主属性必须完全依赖于整个主键，而非主键的一部分。
?关系模式中不存在传递依赖。
●逻辑模型独立于具体技术，是IT人员和业务人员沟通的工具
2.3企业级数据模型的业务价值
企业信息化建设的目的是通过运用信息化技术来提高企业的生产、运营效率，降低运营风险和经营成本，从而增加企业盈利和持续经营的能力。企业级数据模型定义了企业信息化体系的数据标准，是企业内部各应用系统能够实现相互协作、共享数据的前提，是企业信息化建设成功的必要条件，它的业务价值体现在以下几个方面：
?提升数据质量。企业现有系统在与企业级数据模型映射过程中，能够暴露系统之间数据的差异性、内在的冗余数据，可以将许多潜在的数据质
量问题在正式实施之前予以暴露、并解决。
?理清数据所有权。通过将跨业务、跨组织边界的企业数据之间的关联关系、依赖关系进行识别、并文档化，企业级数据模型可以作为数据所有
权管理工具，支持“共享”数据所有权的概念。
?增强系统的可扩展性。企业级数据模型支持可扩展性的数据架构，基于战略业务视角，独立于具体的技术实现，支持可扩展性。能以很小的IT
变更代价适用不断变化的环境。
?整合行业数据。企业级数据模型吸收了企业外部视角，结合行业数据集成框架，提高了企业的行业数据适用性，从而提升了企业共享行业公用
数据的能力，如客户、位置、供应商等基础数据。企业也可以与相关行
业或合作伙伴共享数据。
?整合套装应用软件。通过将套装应用软件映射到企业级数据模型中，提升了企业级数据模型在企业内部的匹配度，并能识别出套装应用软件和
遗留系统之间的集成点，通过打包产品提供一致性、高质量的数据流转
地图。
2.4企业级数据模型与应用系统数据模型间关系
企业级数据模型是企业内部所有应用系统数据模型设计的起点。企业级数据模型与应用系统数据模型之间的关系表现在以下三个方面：
?企业级数据模型是企业内所有应用系统的基础数据模型。在构建企业数据存储架构（ODS、DW、数据集市和应用）之前，首先要基于企业级数
据模型中的企业逻辑模型创建一个应用级逻辑模型，而该模型是企业逻
辑模型的子集，因此，企业逻辑模型是所有数据存储架构的基础模型。
?数据架构框架。企业级数据模型为企业数据设计和数据存储提供了一个数据架构框架，以支撑数据质量、可扩展性和完整性。业务数据需求和
数据源（遗留系统）为企业的数据设计提供“装修材料”。这些“装修
材料”以属性的形式“填充”到企业逻辑模型框架中。
?数据“粘合剂”。企业级数据模型为企业提供了一个数据集成框架，所有的应用级逻辑模型都可以被映射到企业逻辑模型中，企业级数据模
型就像“胶水”，将企业内部所有数据连接在一起，包括套装应用软件。3企业级数据模型设计
3.1模型设计方法
企业级数据模型设计可采用“业务需求驱动自顶向下”和“基于现状驱动自底向上”相结合模式，参照业界参考模型、行业最佳实践，共同形成数据模型。从业务需求驱动入手自顶向下，参照业界参考模型、行业最佳实践搭建数据模型整体框架
通过现状调研获取企业内部业务流程、设计文档、系统模型、接口规范等现状信息，现状驱动自底向上，细化和完善数据模型的设计
3.2模型设计要点
本文不讨论企业级数据模型设计的具体细节，只讨论建模过程中的关键步骤和要点。企业级数据模型设计总体可分为四个步骤：前期准备、主题域模型设计、概念模型设计、逻辑模型设计。
3.2.1前期准备
在企业内部，涉及多个业务部门，对于一个业务问题通常会有多个不同的观点和看法，每个相关人员需要理解和沟通各自的观点和看法。为了阐明和沟通我们的观点，我们需要理顺企业内部所有核心术语定义以及术语定义的关系，形成一个精确的和公认的术语词典表。因此，在构建企业级数据模型之前，需要在企业范围内统一业务术语，在后续建模过程中给相关人员提供一个沟通的基础。
3.2.2主题域模型设计
主题域模型设计凝聚了企业内部中高层管理者的共识，是企业内部各方相互妥协后达成的协议。主题域模型设计过程中注意以下几个要点：?设计依据
设计依据来源于三个方面：立足需求和现状、行业最佳实践和业界理论支撑。
●立足需求和现状。基于企业业务整体发展的需求以及行业监管要求，
在企业范围内开展业务调研、信息调研获取企业的当前现状信息，作
为主题域模型设计的输入信息。
●行业最佳实践。借鉴国际、国内本行业相关企业的实践经验以及相关
工作成果。了解相关企业在数据建模过程中所取得的成就和经验教
训，确保企业在建模过程中少走弯路。
●业界理论支撑。参考业界通用数据模型设计思路，推动业界参考模型
产品的客户化处理。通常，每个行业都会有本行业的参考模型，例如：
金融行业典型的参考模型包括TD FS-LDM和IBM FSDM模型；通信行
业典型参考模型包括NGOSS-SID模型。
?关键要点
●设计过程需要整个企业内部各个部门的广泛参与，有助于形成合力、
达成共识。
●业务专家的深度参与和亲临指导，有助于识别、理解组织架构和业务
功能；
●主题域的定义和命名过程很重要，它有助于覆盖企业的重要业务主
题，避免重大遗漏；
●主题域名称应该清晰、简洁、易于理解；
3.2.3概念模型设计
概念模型设计是从企业角度出发，采用“自上而下”的开发模式。不局限于某个特定业务领域或应用。概念模型设计过程中注意以下几个要点：?两个关键步骤
●识别各主题域下的关键实体，对关键实体再进行细分类。
●识别关键实体及其分类之间的关联关系。
?关键要点
●建立概念模型过程中必须得到业务领域专家和业务负责人的指导，并
由业务用户提供模型的应用需求。
●模型设计师完成初步设计以后，需通过多轮会议，由业务领域专家、
相关主题域的专家验证本主题域概念是否符合要求；
●会议过程中，概念模型初稿暴露出的概念重叠、冲突或其它关注的问
题都将应记录下来，由模型设计师继续调整模型，概念模型的最终成
稿通常需经历多轮迭代，迭代次数取决于概念模型的复杂程度和发现
问题的数量。
3.2.4逻辑模型设计
逻辑模型基于概念模型进行扩展，包括扩充逻辑实体、提取关键数据属性、业务规则、值域填充到逻辑模型当中，它是业务人员、IT人员用来发现、记录
和沟通业务的详细“蓝图”。逻辑模型设计过程中注意以下几个要点：?逻辑模型承载着企业数据标准。通过逻辑模型中的实体、关键属性等可以有效地承载数据标准的内容，并传递到应用系统模型设计中。
?逻辑模型承载着业务数据规则。
●基数规则。例如：定义与两个实体间关系相关的某个实体的实例数量。
譬如下图表示“一个客户可以在银行有多个存款账号，最多有一张白
金理财卡”。基数规则有“一对一、一对多、多对多”三种类型。
●参照性规则。例如：为确保正确有效的数值所定义的规则。譬如下图
表示“存款不能没有存款客户，必须要有一个存款人。
?逻辑模型承载着企业数据质量规则，通过逻辑模型，可以了解数据质量要求，提前数据质量的管控或检测，做到提前预防不合规的数据提交给
下游数据使用者
●针对前页的业务数据规则，可以对系统中数据进行如下质量规则的检
查。例如：检查是否存在持有多张（大于1张）白金理财卡的客户；
检查是否存在没有存款人的存款帐户存在。
●结合逻辑模型中实体属性的域定义的格式、取值范围等，在系统模型
设计时继承该实体属性的质量检测管控，防止不合乎标准的数据进入
系统。
?关键要点
●模型设计师创建逻辑模型的初始版本，通过工作会议的形式，由业务
领域专家进一步验证逻辑模型的完整性和准确性；
●逻辑模型的设计过程需要多轮迭代，迭代次数取决于实体概念的数
量、业务的复杂程度或者发现问题的数量。
4心得体会与总结
本人先后参与了金融数据模型、征信数据模型等多个大型企业的数据模型设计项目，具有扎实的理论基础和丰富的数据模型设计实践经验。通过总结项目期间的经验和教训，分享建模过程中的心得体会，希望对大家能有所帮助。
?企业级数据模型设计应以“自顶向下”方法为主，应通过中高层访谈、规划研读等方式，充分理解公司发展战略目标、业务规划和信息化规划，以便站在企业整体业务视角上，洞察企业数据的全貌性和整体性；
?在模型设计工作开始之前，应首先推动在企业范围内形成统一的业务术语词典，统一业务术语定义，“磨刀不误砍柴工”，各部门业务人员有了
共同的沟通基础，在后续的模型设计工作中就可以起着事半功倍的效
果；
?主题域模型设计中，对于企业一级主题域的划分，并不是一定要按照本企业的主营业务分类作为划分依据，而是从数据模型知识更容易传播、
共享的角度，参照本行业参考模型进行一级主题域划分，这样更利于吸
收企业外部视角、整合行业数据。
?概念模型设计需要业务领域专家的深度参与和业务负责人的亲临指导，模型成果才能紧贴企业实际需要，符合企业要求。业界参考模型和行业
最佳实践，都只是参照物，业务需求才是模型设计工作的主要驱动力。
通过业务领域专家的深度参与，才能获知本企业在该业务领域最关注的
核心概念及分类，才能梳理出核心概念及分类之间的关联关系。业务负
责人则是对设计成果的进一步完善和确认。
?逻辑模型涉及到业务细节问题，同样离不开业务人员的深度参与。需要着重指出的是，逻辑模型是一种通用模型，模型设计师在面对大量的数
据库设计文档、系统模型、接口规范时，应根据设计经验提炼出所需要
的主要实体、关键属性、业务规则，以便对概念模型进行进一步细化和
分解。
?过程比结果更重要。通过建模工作，大家一起去讨论、交流和学习建模方法论、业务知识，共同推进模型设计工作的完善和改进，这本身就比
模型交付结果更重要。因为在这个过程中，员工得到了成长，彼此之间
增强了信任，为下一步的合作奠定基础。
?企业级数据模型的建设不是一劳永逸的，需要持续不断的进行维护和改进。模型成果交付以后，并非静止不动，而是需要由专人持续不断的改进和完善。
建模方法论
第二章建模方法论 2.1 数学模型 系统模型的表示方式有许多，而其中数学方式是系统模型的最主要的表示方式。系统的数学模型是对系统与外部的作用关系及系统内在的运动规律所做的抽象，并将此抽象用数学的方式表示出来。本节将讨论建立数学模型作用、数学模型与集合及抽象的关系、数学建模的形式化表示、数学模型的有效性与建模形式化、数学模型的分类等问题。 2.1.1 数学建模的作用 1、提高认识 通信、思考、理解三个层次。 首先，一个数学描述要提供一个准确的、易于理解的通信模式；除了具有清楚的通信模式外，在研究系统的各种不同问题或考虑选择假设时，需要一个相当规模的辅助思考过程；一旦模型被综合成为一组公理和定律时，这样的模型将使我们更好地认识现实世界的现象。
因此，可把现实世界的系统看成是由可观测和不可观测两部分组成。 2、提高决策能力 管理、控制、设计三个层次。 管理是一种有限的干预方式，通过管理这种方式人们可以确定目标和决定行为的大致过程，但是这些策略无法制定得十分详细。在控制这一层，动作与策略之间的关系是确定的，但是，由于控制中的动作仅限于在某个固定范围内进行选择，所以仍然限制了干预的范围。在设计层，设计者可以在较大程度上进行选择、扩大或代替部分现有的现实，以满足设计者的希望。 因此，可把现实世界的系统看成是由可控制和不可控制两部分组成。 3--- 统实际系统 不可观部分不可控部分
可观部分 可控部分 目标：提高认识 目标： 提高干预能力 图 2.2 根据目标建立系统 2.1.2 集合、抽象与数学模型 抽象过程是建模工程的基础。由于建模和集合论都是以抽象为基础，集合论对于建模工程是非常有用。 1、集合： 有限集合 无限集合，整数集合I,实数集合R ，正整数集 合I +,非负整数集合I 0+=I +U{0}，}{0,0∞=++∞ I I 是非 负整数加符号∞而成的集合。与其类似，R +,R 0 +和+∞,0R 则表示实数的相应集合。 叉积是集合基本运算：令A 和B 是任意集合，则A ×B={（a,b ）,a ∈A,b ∈B}。 2、映射：是一个关系。具有形式：F t t w → 10,:. 3、理论构造
数据仓库建模方法论 2018-3-29
数据仓库建模方法论 通过上一篇数据仓库建设的全局概览，我们认识了数据仓库，也明确了数据建模在仓库建设中的核心地位，数据仓库模型是整个大厦的基石，也是个难点。这么重要的环节就有必要单独拿出来详细说明一下。（本文的重点是维度建模）1什么是数据模型 数据模型是抽象描述现实世界的一种方法，是通过抽象的实体及实体之间的联系来表示现实世界中事务的相互关系的一种映射。 数据仓库模型是数据模型中针对特定的数据仓库应用系统的特定模型。由下图四部分内容组成： ●业务建模，主要解决业务层面的分解和程序化。 ●领域建模，主要对业务模型进行抽象处理，生成领域概念模型。 ●逻辑建模，主要将领域模型的概念实体以及实体之间的关系进行数据库层 次的逻辑化。 ●物理建模，主要解决逻辑模型针对不同关系型数据库的物理化以及性能等 一些具体的技术问题。
2数据仓库数据模型架构 数据仓库模型由五部分组成，如下图： 系统记录域：数据仓库业务数据存储区，模型保证了数据的一致性。（继续使用Oracle？） 内部管理域：也就是元数据模型的存储管理。（工具待定） 汇总域：系统记录域的汇总数据，数据模型保证的主题分析的性能，满足部分报表查询。 分析域：用于各个业务部分的具体的主题分析。也就是数据集市。 反馈域：针对前端反馈的数据，根据业务需求而定。 3数据模型的作用 ●进行全面的业务梳理，改进业务流程。 ●建立全方位的数据视角，打通信息孤岛，去除数据差异。 ●解决业务的变动，提高数据仓库灵活性。 ●帮助数据仓库系统本身的建设。
4如何创建数据仓库模型 4.1数据仓库建模四个阶段 4.1.1业务建模 ●划分整个企业的业务，一般按部门划分，进行各个部分之间业务工作 的界定，理清各业务部门之间的关系。 ●深入了解各业务部门工作流程的方法。 ●提出修改和改进业务部门工作流程的方法。 ●数据建模的范围界定，确定数据仓库项目的目标和阶段划分。 4.1.2领域概念建模 ●抽取关键业务概念，并抽象化。 ●将业务概念分组，按业务主线聚合类似的分组概念。 ●细化分组概述，理清分组概念内的精力流程并抽象化。 ●理清分组概念之间的关联，形成完整的领域概念模型。 4.1.3逻辑建模 业务概念实体化、事实实体化、说明实体化，并考虑其属性内容。 4.1.4物理建模 ●针对特定物理平台做出相应的技术调整 ●针对模型的性能考虑，结合特定平台做出相应调整
企业数据模型设计方法论探讨
企业数据模型设计方法论探讨
————————————————————————————————作者：————————————————————————————————日期：
企业级数据模型设计方法论探讨 1引言 数据模型设计是一个老生常谈的话题，在以往的数据仓库BI项目中，数据模型的方法论、概念通常大多围绕如何设计和建设数据仓库，而应用系统（OLTP 系统）模型设计却缺乏方法论的指导，加之各应用系统通常都是由不同厂商在不同时期自行设计开发，彼此之间缺乏沟通，导致数据分散重复、口径不一致和数据兼容性差。由于数据仓库在企业整体信息化规划中属于下游系统，只能被动接收由各应用系统产生的数据，数据入仓之后，由于口径不一致、兼容性差，给数据整合带来极大困难。企业在投入大量的人力、物力和资金推进信息化建设，仍然出现大量的“信息孤岛”现象。 本文认为，企业信息化建设的成功很大程度上取决于系统模型的合理性和不同系统间概念的一致性，而企业级数据模型是企业信息化的核心问题，通过企业级数据模型定义整个企业信息化体系的数据标准，逐步统一企业内部数据标准，指导各应用系统数据模型统一设计，可以从根本上保证系统之间数据的兼容性和一致性，消除由于各应用系统自行设计开发而导致的数据分散重复、口径不一致和信息孤岛现象，推动企业内各类应用系统的整合和数据的共享，全面提升经营决策、运营管理、业务拓展和客户服务等方面的支撑能力。 本文将首先阐述企业级数据模型的定义和结构，分析其业务价值。通过描述企业级数据模型与应用系统模型间关系，划分两者之间的概念边界和区别，从而更好的理解企业级数据模型的真正内涵。其次，阐述了企业级数据模型设计的基本方法和关键要点，使读者能够掌握企业级数据模型设计的整体思路，以便对后续工作提供借鉴和指导作用。最后，总结了多个项目的经验教训，分享企业级数据模型建模过程中的心得体会，希望对大家能有所帮助。 2企业级数据模型定义 2.1模型基本定义 企业级数据模型不能等同于数据仓库模型，企业级数据模型是站在整个企业
数据库建模步骤分解
数据库模型设计方法论 一、设计的原则、宗旨 1) 多与用户互动 2) 建模过程遵循结构化方法论 3) 引入数据驱动方法data-driven approach 4) 综合考虑数据模型的结构和完整型 5) 建模方法论中结合概念化、范式化、交易验证技术 6) 多用图表表达模型 7) 完善的文档表达数据语义 8) 创建数据字典完善和补足数据模型 9) 反复/重复设计步骤 二、设计阶段 1) 概念数据模型设计-CDM 2) 逻辑数据模型设计-LDM 3) 物理数据模型设计-PDM 三、设计步骤 1 需求分析 1.1环境和需求分析成果物：高阶信息流图 1.2系统分析和系统细化成果物：工作流图，工作表 工作表构成： 工作编号 工作名称 发起人 目的 触发条件 描述 频度 周期 重要度 最大延时 输入 输出 用到文档 动作 子工作 出错条件
2 为每个用户视图建立概念模型 2.1识别实体 2.2识别关系(has manage own hold view rent made of .etc) 2.3识别并关联实体或关系的属性 derived attribute 2.4确定属性域（DD） 2.5确定候选/主关键字 2.6具化/泛化实体类型（optional） 2.7 画ER图 2.8同用户审查LCDM 3 建立和验证LLDM 3.1局部CDM到局部LDM的映射 去除 M：N关系 去除复杂关系 去除属性循环关系 Remove relationships with attributes 去除多值属性 复核1:1关系 去除冗余关系 3.2 局部LDM中引出关系（derive Relations from LLDM） 3.3 用范式化理论验证模型 3.4用用户交易验证模型 3.5画ER图 3.6定义完整性约束 3.7同用户审查审核LLDM 4 建立和验证GLDM 4.1合并/集成LLDM 4.2验证GLDM 4.3验证未来增长 check for future growth 4.4 画最终ER图
企业数据模型设计方法论探讨
企业级数据模型设计方法论探讨 1引言 数据模型设计是一个老生常谈的话题，在以往的数据仓库BI项目中，数据模型的方法论、概念通常大多围绕如何设计和建设数据仓库，而应用系统（OLTP系统）模型设计却缺乏方法论的指导，加之各应用系统通常都是由不同厂商在不同时期自行设计开发，彼此之间缺乏沟通，导致数据分散重复、口径不一致和数据兼容性差。由于数据仓库在企业整体信息化规划中属于下游系统，只能被动接收由各应用系统产生的数据，数据入仓之后，由于口径不一致、兼容性差，给数据整合带来极大困难。企业在投入大量的人力、物力和资金推进信息化建设，仍然出现大量的“信息孤岛”现象。 本文认为，企业信息化建设的成功很大程度上取决于系统模型的合理性和不同系统间概念的一致性，而企业级数据模型是企业信息化的核心问题，通过企业级数据模型定义整个企业信息化体系的数据标准，逐步统一企业内部数据标准，指导各应用系统数据模型统一设计，可以从根本上保证系统之间数据的兼容性和一致性，消除由于各应用系统自行设计开发而导致的数据分散重复、口径不一致和信息孤岛现象，推动企业内各类应用系统的整合和数据的共享，全面提升经营决策、运营管理、业务拓展和客户服务等方面的支撑能力。 本文将首先阐述企业级数据模型的定义和结构，分析其业务价值。通过描述企业级数据模型与应用系统模型间关系，划分两者之间的概念边界和区别，从而更好的理解企业级数据模型的真正内涵。其次，阐述了企业级数据模型设计的基本方法和关键要点，使读者能够掌握企业级数据模型设计的整体思路，以便对后续工作提供借鉴和指导作用。最后，总结了多个项目的经验教训，分享企业级数据模型建模过程中的心得体会，希望对大家能有所帮助。 2企业级数据模型定义 模型基本定义 企业级数据模型不能等同于数据仓库模型，企业级数据模型是站在整个企业业务的视角，对企业全部数据（包括生产数据和消费数据）全貌性、整体性描述。企业级数据模型是业务人员和IT人员进行沟通的媒介、也是企业内部与外部进行交流的纽带。
系统设计方案模板
系统设计方案模板[文档副标题]
1 引言 1.1 编写目的 说明编写详细设计方案的主要目的。 详细设计的主要任务是对概要设计方案做完善和细化。说明书编制的目的是说明一个软件系统各个层次中的每个程序（每个模块或子程序）和数据库系统的设计考虑，为程序员编码提供依据。如果一个软件系统比较简单，层次很少，本文件可以不单独编写，和概要设计说明书中不重复部分合并编写。 方案重点是模块的执行流程和数据库系统详细设计的描述。 1.2 背景 应包含以下几个方面的内容： A. 待开发软件系统名称 B. 该系统基本概念，如该系统的类型、从属地位等 C. 开发项目组名称 D. 项目代号（项目规划所采用的代号）； E. 说明遵从的IT标准和原则，符合公司的IT ABBs 1.3 参考资料 列出详细设计报告引用的文献或资料，资料的作者、标题、出版单位和出版日期等信息，必要时说明如何得到这些资料。 1.4 术语定义及说明 列出本文档中用到的可能会引起混淆的专门术语、定义和缩写词的原文。 2 设计概述 2.1 任务和目标 说明详细设计的任务及详细设计所要达到的目标。
2.1.1 需求概述 对所开发软件的概要描述, 包括主要的业务需求、输入、输出、主要功能、性能等，尤其需要描述系统性能需求。 2.1.2 运行环境概述 对本系统所依赖于运行的硬件，包括操作系统、数据库系统、中间件、接口软件、可能的性能监控与分析等软件环境的描述，及配置要求。 2.1.3 条件与限制 详细描述系统所受的内部和外部条件的约束和限制说明。包括业务和技术方面的条件与限制以及进度、管理等方面的限制。 2.1.4 详细设计方法和工具 简要说明详细设计所采用的方法和使用的工具。如HIPO图方法、IDEF（I2DEF）方法、E－R 图，数据流程图、业务流程图、选用的CASE工具等，尽量采用标准规范和辅助工具。 3 系统详细需求分析 主要对系统级的需求进行分析。首先应对需求分析提出的企业需求进一步确认，并对由于情况变化而带来的需求变化进行较为详细的分析。 3.1 详细需求分析 包括： ●详细功能需求分析 ●详细性能需求分析 ●详细资源需求分析 ●详细系统运行环境及限制条件分析 3.2 详细系统运行环境及限制条件分析接口需求分析 包括： ●系统接口需求分析
数据挖掘方法论(SEMMA)
SAS数据挖掘方法论─ SEMMA (2009-07-20 21:15:48) Sample ─数据取样 Explore ─数据特征探索、分析和予处理 Modify ─问题明确化、数据调整和技术选择 Model ─模型的研发、知识的发现 Assess ─模型和知识的综合解释和评价 Sample──数据取样 当进行数据挖掘时，首先要从企业大量数据中取出一个与你要探索问题相关的样板数据子集，而不是动用全部企业数据。这就象在对开采出来矿石首先要进行选矿一样。通过数据样本的精选，不仅能减少数据处理量，节省系统资源，而且能通过数据的筛选，使你想要它反映的规律性更加凸现出来。 通过数据取样，要把好数据的质量关。在任何时候都不要忽视数据的质量，即使你是从一个数据仓库中进行数据取样，也不要忘记检查其质量如何。因为通过数据挖掘是要探索企业运作的规律性的，原始数据有误，还谈什么从中探索规律性。若你真的从中还探索出来了什么“规律性”，再依此去指导工作，则很可能是在进行误导。若你是从正在运行着的系统中进行数据取样，则更要注意数据的完整性和有效性。再次提醒你在任何时候都不要忽视数据的质量，慎之又慎！ 从巨大的企业数据母体中取出哪些数据作为样本数据呢？这要依你所要达到的目标来区分采用不同的办法：如果你是要进行过程的观察、控制，这时你可进行随机取样，然后根据样本数据对企业或其中某个过程的状况作出估计。SAS不仅支持这一取样过程，而且可对所取出的样本数据进行各种例行的检验。若你想通过数据挖掘得出企业或其某个过程的全面规律性时，必须获得在足够广泛范围变化的数据，以使其有代表性。你还应当从实验设计的要求来考察所取样数据的代表性。唯此，才能通过此后的分析研究得出反映本质规律性的结果。利用它支持你进行决策才是真正有效的，并能使企业进一步获得技术、经济效益。 Explore──数据特征探索、分析和予处理 前面所叙述的数据取样，多少是带着人们对如何达到数据挖掘目的的先验的认识进行操作的。当我们拿到了一个样本数据集后，它是否达到我们原来设想的要求；其中有没有什么明显的规律和趋势；有没有出现你所从未设想过的数据状态；因素之间有什么相关性；它们可区分成怎样一些类别……这都是要首先探索的内容。 进行数据特征的探索、分析，最好是能进行可视化的操作。SAS有：SAS/INSIGHT和SAS/SPECTRA VIEW两个产品给你提供了可视化数据操作的最强有力的工具、方法和图形。它们不仅能做各种不同类型统计分析显示，而且可做多维、动态、甚至旋转的显示。