基于事例处理的工程项目工作流管理

分析31 重点：软件开发方法、CMM、成本估算、风险分析、进度管理、人员管理、软件开发环境 32 系统分析基础知识 · 系统分析的目的和任务 · 结构化分析方法（数据流图（DFD）、数据字典（DD）、实体关系图（ERD）、描述加工处理的结构化语言） · 统一建模语言（UML） · 系统规格说明书 分析32 高度重视UML在系统分析中的应用 重点：数据流图（DFD）、数据字典（DD）、实体关系图（ERD） 考点：UML的各类图 33 系统设计知识 · 系统设计的目的和任务 · 结构化设计方法和工具（系统流程图、HIPO图、控制流程图） · 系统总体结构设计（总体布局、设计原则、模块结构设计、数据存储设计、系统配置方案） · 系统详细设计（代码设计、数据库设计、用户界面设计、处理过程设计） · 系统设计说明书 分析33 重点：系统流程图、HIPO图、控制流程图 34 系统实施知识 · 系统实施的主要任务 · 结构化程序设计、面向对象程序设计、可视化程序设计 · 程序设计风格 · 程序设计语言的选择 · 系统测试的目的、类型，系统测试方法（黑盒测试、白盒测试、灰盒测试） · 测试设计和管理（错误曲线、错误排除、收敛、注入故障、测试用例设计、系统测试报告） · 系统转换基础知识 35 系统运行和维护知识 · 系统运行管理基础知识 · 系统维护基础知识 · 系统评价基础知识 分析34/35 重点：结构化设计中信息流、变换分析、系统结构设计原则、系统划分、模块设计、数据存储设计、面向对象程序设计、测试方法、系统维护的分类 难点：系统测试方法、测试分类、系统可维护性评价指标 36 面向对象开发方法 · 面向对象开发概念（类、对象、属性、封装性、继承性、多态性、对象之间的引用） · 面向对象开发方法的优越性以及有效领域 · 面向对象设计方法（体系结构、类的设计、用户接口设计） · 面向对象实现方法（选择程序设计语言、类的实现、方法的实现、用户接口的实现、准备测试数据） · 面向对象程序设计语言（如C++、Java、Visual、Bsasic、Visual C++）的基本机制 · 面向对象数据库、分布式对象的概念 分析36 重点：面向对象开发：类、对象、属性、封装性、继承性、多态性、OMT方法 难点：建议在数据流图、结构化分析方法上多加掌握。 分析3 考试题型一般分布在：DFD、软件的生存周期；数据流图；模块间的关系；软件测试的分类、软件质量管理（标准）软件的特性、主要的软件开发方法、系统测试、软件能力成熟评估 考试出现频率较高的内容：数据流图、黑盒/白盒测试、面向对象技术的概念 4．安全性知识 · 安全性基本概念 · 防治计算机病毒、防范计算机犯罪 · 存取控制、防闯入、安全管理措施 · 加密与解密机制 · 风险分析、风险类型、抗风险措施和内部控制 分析4 系统安全问题是目前社会关注的问题，也是应用价值较高的知识，可结合现实中的相关问题来加深理解。 考试出现频率较高的内容：加密与解密算法、 5．标准化知识 · 标准化意识、标准化的发展、标准制订过程 · 国际标准、国家标准、行业标准、企业标准基本知识 · 代码标准、文件格式标准、安全标准、软件开发规范和文档标准知识 · 标准化机构 6．信息化基础知识 · 信息化意识 · 全球信息化趋势、国家信息化战略、企业信息化战略和策略 · 有关的法律、法规 · 远程教育、电子商务、电子政务等基础知识 · 企业信息资源管理基础知识 分析5/6 信息化、标准化知识是新增考点。标准化方面有标准标识，标准修订等是对基本素质的考查，也要重视。 考试出现频率较高的内容 7．计算机专业英语 · 掌握计算机技术的基本词汇 · 能正确阅读和理解计算机领域的英文资料 分析7 专业英语，是对专业知识和英语水平的考查，考前需有意识阅读点英文专业资料。 考试题型一般分布在：软件行业标准，计算机安全基础知识，信息化基础知识。 考试出现频率较高的内容：行业标准的类别；计算机安全，CMM分类，计算机软件著作权问题。 考试科目2：软件设计 本部分具体内容如下： l 外部设计 l 内部设计 l 程序设计 l 系统实施 l 软件工程 本部分所涉及内容为软件设计的日常工作，这些内容同样出现在上午考试试题中。 1．外部设计 11 理解系统需求说明 12 系统开发的准备 · 选择开发方法、准备开发环境、制订开发计划 13 设计系统功能 · 选择系统结构，设计各子系统的功能和接口，设计安全性策略、需求和实现方法，制订详细的工作流和数据流 14 设计数据模型 · 设计ER模型、数据模型 15 编写外部设计文档 · 系统配置图、各子系统关系图、系统流程图、系统功能说明书、输入输出规格说明、数据规格说明、用户手册框架 · 设计系统测试要求 16 设计评审 应能由考试说明内容，来阅读 2．内部设计 21 设计软件结构 · 按构件分解，确定构件功能规格以及构件之间的接口 · 采用中间件和工具 22 设计输入输出 · 屏幕界面设计、设计输入输出检查方法和检查信息 23 设计物理数据 · 分析数据特性，确定逻辑数据组织方式、存储介质，设计记录格式和处理方式 · 将逻辑数据结构换成物理数据结构，计算容量，进行优化 24 构件的创建和重用 · 创建、重用构件的概念 · 使用子程序库或类库 25 编写内部设计文档 · 构件划分图、构件间的接口、构件处理说明、屏幕设计文档、报表设计文档、文件设计文档、数据库设计文档 26 设计评审 3．程序设计 31 模块划分（原则、方法、标准） 32 编写程序设计文档 · 模块规格说明书（功能和接口说明、程序处理逻辑的描述、输入输出数据格式的描述） · 测试要求说明书（测试类型和目标、测试用例、测试方法） 33 程序设计评审 4．系统实施 41 配置计算机系统及其环境 42 选择合适的程序设计语言 43 掌握C程序设计语言，以及C++、Java、Visual Basic、Visual C++中任一种程序设计语言，以便能指导程序员进行编程和测试，并进行必要的优化 44 系统测试 · 指导程序员进行模块测试，并进行验收 · 准备系统集成测试环境和测试工具 · 准备测试数据 · 写出测试报告 5．软件工程 · 软件生存期模型（瀑布模型、螺旋模型、喷泉模型）和软件成本模型 · 定义软件需求（系统化的目标、配置、功能、性能和约束） · 描述软件需求的方法（功能层次模型、数据流模型、控制流模型、面向数据的模型、面向对象的模型等） · 定义软件需求的方法（结构化分析方法、面向对象分析方法） · 软件设计（分析与集成、逐步求精、抽象、信息隐蔽） · 软件设计方法（结构化设计方法、Jackson方法、Warnier方法、面向对象设计方法） · 程序设计（结构化程序设计、面向对象程序设计） · 软件测试的原则与方法 · 软件质量（软件质量特性、软件质量控制） · 软件过程评估基本方法、软件能力成熟度评估基本方法 · 软件开发环境和开发工具（分析工具、设计工具、编程工具、测试工具、维护工具、CASE） · 软件工程发展趋势（面向构件，统一建模语言（UML）） · 软件过程改进模型和方法 本部分综合分析： 软件设计师，关键是设计软件的能力。考纲要求：要熟悉软件工程、软件过程改进和软件开发项目管理的基础知识；熟练掌握软件设计的方法和技术；掌握C程序设计语言及指定的四种面向对象语言中的一种。这部分专业能力严重依赖工作实践，要求有一定经验的积累，是具有工程师的实际工作能力和业务水平的体现。如无实践经验，要学会借鉴，以取人之长，补已之短。 这部分主要体现在下午考试中，现就如何应对下午考试进行分析： 近几次考试中下午试题分五个题目，一个数据库，一个程序填空题、一个面向对象的语言题，另两个题目分别为数据流图、UML、或流程图等。 数据库题目，要求补全SQL语言，这要求考生熟悉SQL的语言，无论对上午题目还是下午题目都很重要。这是学习和复习的一个重点。 数据流图，DFD是一种分析系统数据流程的图形，意在让用户理解系统的功能、输入、输出和数据存储等。请认真弄清其应用，在画出数据流图的情况下，系统的功能也就确定了，再经过细化，逐步向物理结构迈进。考核时，试题多从父图和子图的平衡来分析。这部分内容，一个解题的关键是高度重视题目说明，务必正确、深入理解其内容，必要时要读几遍，同时对于给出的图表，也要务必看懂。这样答题就轻松了，答案实际就蕴含在说明中。 流程图类题目，是大家再熟悉不过的了，它就一个具体问题的解题思路进行描述，是面向过程的。但所求问题是千差万别的，因此应理解思路，细心作答。 答题形式最简单也是难度最大的是程序填空。为便于阅卷，这类题目以程序填空形式出现，这不仅要求理解问题本质，同时也要弄清作者解题思路，这一点比自己独立完成程序设计要难得的多。针对问题，首先设计自己的思路，如何解决问题，先后顺序怎样；然后试读程序，如何思路大体一致，很好，这题容易解决了。如思路不一致，设法弄清每一段代码的功能，其逻辑结构怎样，进而弄清命题人的解题思路，再顺势解决问题。人们常讲，答案就在题目中，这是对的。在分析问题过程中，找到所求答案。不过前提条件是考生要熟悉这种语言，又要明白解题思路，这样才能正确作答。这个题目比较难，要么不得分，要么得全分。 近年对于统一建模语言UML考查较多，已引起了考生的注意。它代表了软件工程的发展趋势，目前是可视化建模的事实上的工业标准。人们对于图的理解相对其他形式更容易一些，图能更清晰地描述和说明问题的本质，因此，UML体现了这一特点。这类题目难度与数据流图相似，自然解题思想也相同。从形式上看，数据流图更朴实一些，UML类的题目则透出一种新颖、现代的气息。 最后的题目面向对象语言是一个选做题，给考生以自由，可以发挥个人的优势。命题已注意到不同语言的考查难度一致性，要求考生就同一问题回答，实现了形式上的公平，自然是一个进步

‍

数据仓库的定义？

首先，用于支持决策，面向分析型数据处理；其次，对多个异构的数据源有效集成，集成后按照主题进行重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。

数据仓库(Data Warehouse)是一个面向主题的(subject oriented)、集成的(integrated)、相对稳定的(non-volatile)、反应历史变化(time variant)的数据集合，用于支持管理决策(decision making support)。

数据仓库和数据库的区别？

从目标、用途、设计来说

数据库是面向事物处理的，数据是由日常的业务产生的，常更新；数据仓库是面向主题的，数据来源多样，经过一定的规则转换得到，用来分析。数据库一般用来存储当前事务性数据，如交易数据；数据仓库一般存储的历史数据。数据库的设计一般是符合三范式的，有最大的精确度和最小的冗余度，有利于数据的插入；数据仓库的设计一般不符合三范式，有利于查询

如何构建数据仓库？

数仓模型的选择是灵活的，不局限于某种模型方法。

数仓数据是灵活的，以实际需求场景为导向。

数仓设计要兼顾灵活性、可扩展性，要考虑技术可靠性和实现成本。

系统分析，确定主题。通过与业务部门的交流，了解建立数仓要解决的问题，确认各个主题下的查询分析要求选择满足数据仓库系统要求的软件平台。选择合适的软件平台，包括数据库、建模工具、分析工具等建立数据仓库的逻辑模型。确定建立数据仓库逻辑模型的基本方法，基于主题视图，把主题视图中的数据定义转到逻辑数据模型中逻辑数据模型转换为数据仓库数据模型数据仓库数据模型优化。随着需求和数据量的变化进行调整数据清洗转换和传输。业务系统中的数据加载到数据仓库之前，必须进行数据的清洗和转换，保证数据仓库中数据的一致性。开发数据仓库的分析应用。满足业务部门对数据进行分析的需求。数据仓库的管理。包括数据库管理和元数据管理。

什么是数据中台？

数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台吧数据统一之后，会形成标准数据，再进行存储，形成大数据资产层，进而为客户提供高效服务。

这些服务和企业的业务有较强的关联性，是企业所独有且能复用的，它是企业业务和数据的积淀，其不仅能降低重复建设，减少烟囱式协作的成本，也是差异化竞争的优势所在。

数据中台通过整合公司开发工具、打通全域数据、让数据持续为业务赋能，实现数据平台化、数据服务化和数据价值化。数据中台更加侧重于“复用”与“业务”。

数据中台、数据仓库、大数据平台的关键区别是什么？

基础能力上的区别

数据平台：提供的是计算和存储能力

数据仓库：利用数据平台提供的计算和存储能力，在一套方法论指导下建设的一整套的数据表

数据中台：包含了数据平台和数据仓库的所有内容，将其打包，并且以更加整合以及更加产品化的方式对外提供服务和价值。

业务能力上的区别

数据平台：为业务提供数据主要方式是提供数据集

数据仓库：相对具体的功能概念是存储和管理一个或多个主题数据的集合，为业务提供服务的方式主要是分析报表

数据中台：企业级的逻辑概念，提现企业数据产生价值的能力，为业务提供服务的主要方式是数据API

总的来说，数据中台距离业务更近，数据复用能力更强，能为业务提供速度更快的服务。数据中台是在数据仓库和数据平台的基础上，将数据生产为一个个数据API服务，以更高效的方式提供给业务。数据中台可以建立在数据仓库和数据平台之上，是加速企业从数据到业务价值的过程的中间层。

大数据的一些相关系统？

数仓设计中心：按照主题域、业务过程，分层的设计方式，以维度建模作为基本理论依据，按照维度、度量设计模型，确保模型、字段有统一的命名规范

数据资产中心：梳理数据资产，基于数据血缘，数据的访问热度，做成本的治理

数据质量中心：通过丰富的稽查监控系统，对数据进行事后校验，确保问题数据第一时间被发现，避免下游的无效计算，分析数据的影响范围。

指标系统：管理指标的业务口径、计算逻辑和数据来源，通过流程化的方式，建立从指标需求、指标开发、指标发布的全套协作流程。

数据地图：提供元数据的快速索引，数据字典、数据血缘、数据特征信息的查询，相当于元数据中心的门户。

如何建设数据中台？

数据中台在企业落地实践时，结合技术、产品、数据、服务、运营等方面，逐步开展相关工作。

理现状。了解业务现状、数据现状、IT现状、现有的组织架构定架构。确认业务架构、技术架构、应用架构、组织架构建资产。建立贴近数据层、统一数仓层、标签数据层、应用数据层用数据。对数据进行输出、应用。数据运营。持续运营、持续迭代。

中台建设需要有全员共识，由管理层从上往下推进，由技术和业务人员去执行和落地是一个漫长的过程，在实施数据中台时，最困难的地方就是需要有人推动。

数据湖的理解？

数据湖是一个存储企业的各种各样原始数据的大型仓库，其中的数据可供存取、处理、分析及传输。

数仓最重要的是什么？

个人认为是数据集成。

企业的数据通常是存储在多个异构数据库中的，要进行分析，必须先要对数据进行一致性整合。

集成整合后才可以对数据进行分析、挖掘数据潜在的价值。

概念数据模型、逻辑数据模型、物理数据模型

概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。

概念数据模型CDM

概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，以数据类的方式描述企业级的数据需求。

概念数据模型的内容包括重要的实体与实体之间的关系。在概念数据模型中不包含实体的属性，也不包含定义实体的主键

概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系

逻辑数据模型LDM

逻辑数据模型反应的是系统分析设计人员对数据存储的观点，是对概念数据模型的进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项以及业务对象之间关系的基本蓝图。

逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。

逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑在物理上如何实现。

物理数据模型PDM

物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。

物理数据模型的内容包括确定所有的表和列，定义外键用于确认表之间的关系，基于用户的需求可能要进行反范式化等内容。

SCD的常用处理方式？

slowly changing dimensions缓慢变化维度

不记录历史变化信息添加列来记录历史变化新插入数据行，并添加对应标识字段来记录历史数据。拉链表。

元数据的理解？

狭义来讲就是用来描述数据的数据

广义来看，除了业务逻辑直接读写处理的业务数据，所有其他用来维护整个系统运转所需要的数据，都可以较为元数据。

定义：元数据metadata是关于数据的数据。在数仓系统中，元数据可以帮助数据仓库管理员和数据仓库开发人员方便的找到他们所关心的数据；元数据是描述数据仓库内部数据的结构和建立方法的数据。按照用途可分为：技术元数据、业务元数据。

技术元数据

存储关于数据仓库技术细节的数据，用于开发和管理数据仓库使用的数据

数据仓库结构的描述，包括数据模式、视图、维、层次结构和导出数据的定义，以及数据集市的位置和内容业务系统、数据仓库和数据集市的体系结构和模式由 *** 作环境到数据仓库环境的映射，包括元数据和他们的内容、数据提取、转换规则和数据刷新规则、权限等。

业务元数据

从业务角度描述了数据仓库中的数据，他提供了介于使用者和实际系统之间的语义层，使不懂计算机技术的业务人员也能读懂数仓中的数据。

企业概念模型：表示企业数据模型的高层信息。整个企业业务概念和相互关系。以这个企业模型为基础，不懂sql的人也能做到心中有数多维数据模型。告诉业务分析人员在数据集市中有哪些维、维的类别、数据立方体以及数据集市中的聚合规则。业务概念模型和物理数据之间的依赖。业务视图和实际数仓的表、字段、维的对应关系也应该在元数据知识库中有所体现。

元数据管理系统？

元数据管理往往容易被忽视，但是元数据管理是不可或缺的。一方面元数据为数据需求方提供了完整的数仓使用文档，帮助他们能自主快速的获取数据；另一方面数仓团队可以从日常的数据解释中解脱出来，无论是对后期的迭代更新还是维护，都有很大的好处。元数据管理可以让数据仓库的应用和维护更加的高效。

元数据管理功能

数据地图：以拓扑图的形式对数据系统的各类数据实体、数据处理过程元数据进行分层次的图形化展示，并通过不同层次的图形展现。元数据分析：血缘分析、影响分析、实体关联分析、实体差异分析、指标一致性分析。辅助应用优化：结合元数据分析功能，可以对数据系统的应用进行优化。辅助安全管理：采用合理的安全管理机制来保障系统的数据安全；对数据系统的数据访问和功能使用进行有效监控。基于元数据的开发管理：通过元数据管理系统规范日常开发的工作流程

元数据管理标准

对于相对简单的环境，按照通用的元数据管理标准建立一个集中式的元数据知识库

对于比较复杂的环境，分别建立各部分的元数据管理系统，形成分布式元数据知识库，然后通过建立标准的元数据交换格式，实现元数据的集成管理。

数仓如何确定主题域？

主题

主题是在较高层次上将数据进行综合、归类和分析利用的一个抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，它是对企业中某一宏观分析领域所涉及的分析对象。

面向主题的数据组织方式，就是在较高层次上对分析对象数据的一个完整并且一致的描述，能刻画各个分析对象所涉及的企业各项数据，以及数据之间的联系。

主题是根据分析的要求来确定的。

主题域

从数据角度看（集合论）

主题语通常是联系较为紧密的数据主题的集合。可以根据业务的关注点，将这些数据主题划分到不同的主题域。主题域的确定由最终用户和数仓设计人员共同完成。

从需要建设的数仓主题看（边界论）

主题域是对某个主题进行分析后确定的主题的边界。

数仓建设过程中，需要对主题进行分析，确定主题所涉及到的表、字段、维度等界限。

确定主题内容

数仓主题定义好以后，数仓中的逻辑模型也就基本成形了，需要在主题的逻辑关系中列出属性和系统相关行为。此阶段需要定义好数据仓库的存储结构，向主题模型中添加所需要的信息和能充分代表主题的属性组。

如何控制数据质量？

校验机制，每天进行数据量的比对 select count()，早发现，早修复

数据内容的比对，抽样比对

复盘、每月做一次全量

如何做数据治理？

数据治理不仅需要完善的保障机制，还需要理解具体的治理内容，比如数据应该怎么进行规范，元数据该怎么来管理，每个过程需要那些系统或者工具来配合？

数据治理领域包括但不限于以下内容：数据标准、元数据、数据模型、数据分布、数据存储、数据交换、数据声明周期管理、数据质量、数据安全以及数据共享服务。

模型设计的思路？业务驱动？数据驱动？

构建数据仓库有两种方式：自上而下、自下而上

Bill Inmon推崇自上而下的方式，一个企业建立唯一的数据中心，数据是经过整合、清洗、去掉脏数据、标准的、能够提供统一的视图。要从整个企业的环境入手，建立数据仓库，要做很全面的设计。偏数据驱动

Ralph Kimball推崇自下而上的方式，认为数据仓库应该按照实际的应用需求，架子啊需要的数据，不需要的数据不要加载到数据仓库中。这种方式建设周期短，用户能很快看到结果。偏业务驱动

数据质量管理

数据质量管理是对数据从计划、获取、存储、共享、维护、应用、消亡生命周期的每个阶段里可能引发的数据质量问题，进行识别、度量、监控、预警等，通过改善了提高组织的管理水平使数据质量进一步提高。

数据质量管理是一个集方法论、技术、业务和管理为一体的解决方案。放过有效的数据质量控制手段，进行数据的管理和控制，消除数据质量问题，从而提高企业数据变现的能力。

会遇到的数据质量问题：数据真实性、数据准确性、数据一致性、数据完整性、数据唯一性、数据关联性、数据及时性

什么是数据模型？

数据模型就是数据组织和存储的方法，通过抽象的实体以及实体间联系的形式来表达现实世界中事务的相互关系的一种映射，他强调从业务、数据存取和使用角度合理的存储数据。

为什么需要数据仓库建模？

数仓建模需要按照一定的数据模型，对整个企业的数据进行采集，整理，提供跨部门、完全一致的报表数据。

合适的数据模型，对于大数据处理来讲，可以获得得更好的性能、成本、效率和质量。良好的模型可以帮助我们快速查询数据，减少不必要的数据冗余，提高用户的使用效率。

数据建模进行全方面的业务梳理，改进业务流程，消灭信息孤岛，更好的推进数仓系统的建设。

OLAP和OLTP的模型方法的选择？

OLTP系统是 *** 作事物型系统，主要数据 *** 作是随机读写，主要采用满足3NF的实体关系模型存储数据，在事物处理中解决数据的冗余和一致性问题。

OLAP系统是分析型系统，主要数据 *** 作是批量读写，不需要关注事务处理的一致性，主要关注数据的整合，以及复杂大数据量的查询和处理的性能。

3范式

每个属性值唯一，不具有多义性

每个非主属性必须完全依赖于整个主键，而非主键的一部分

每个非主属性不能依赖于其他关系中的属性

数据仓库建模方法？

有四种模型：ER模型、维度模型、Data Vault模型、Anchor模型。用的较多的是维度模型和ER模型。

ER模型

ER模型用实体关系模型描述企业业务，在范式理论上满足3NF。数仓中的3NF是站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系的抽象。

采用ER模型建设数据仓库模型的出发点是整合数据，将各个系统中的数据按照主题进行相似性整合，并进行一致性处理。

ER模型特点：

需要全方位了解企业业务数据

实施周期较长

对建模人员要求教高

维度建模

维度建模按照事实表和维度表来构建数仓。

维度建模从分析决策的需求出发构建模型，为分析需求服务。重点关注用户如何快速的完成数据分析，可以直观的反应业务模型中的业务问题，需要大量的数据预处理、数据冗余，有较好的大规模复杂查询的响应性能。

事实表

发生在现实世界中的 *** 作性事件，其产生的可度量数值，存储在事实表中。从最细粒度级别来看，事实表的一行对应一个度量事件。事实表表示对分析主题的度量。

事实表中包含了与各个维度表相关联的外键，可与维度表关联。事实表的度量通常是数值类型，且记录数不断增加，表数据量迅速增长。

维度表

维度表示分析数据时所用的环境。

每个维度表都包含单独的主键列。维度表行的描述环境应该与事实表行完全对应。维度表通常比较宽，是扁平型的非规范表，包含大量的低粒度的文本属性。

注意：

事实表的设计是以能够正确记录历史信息为准则

维度表的设计是以能够以合适的角度来聚合主题内容为准则

维度建模的三种模式

星形模型：以事实表为中心，所有的维度直接连接在事实表上。由一个事实表和一组维度表组成。

雪花模型：是对星形模型的扩展。雪花模型的维度表可以拥有更细的维度，比星形更规范一点。维护成本较高，且查询是要关联多层维表，性能较低

星座模型：基于多张事实表，多张事实表共享维度信息

维度建模步骤：

选择业务过程

选择粒度

选定事实表

选择维度

事实表的类型？

事实表有：事务事实表、周期快照事实表、累积快照事实表、非事实事实表

事务事实表

事务事实表记录的是事务层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务记录一条记录。

周期快照事实表

以具有规律性的、可预见的时间间隔来记录事实。它统计的是间隔周期内的度量统计，每个时间段一条记录，是在事务事实表之上建立的聚集表。

累积快照事实表

累积快照表记录的不确定的周期的数据。代表的是完全覆盖一个事务或产品的生命周期的时间跨度，通常具有多个日期字段，用来记录整个生命周期中的关键时间点。

非事实型事实表

在维度建模的数据仓库中，有一种事实表叫Factless Fact Table，中文一般翻译为“非事实型事实表”。在事实表中，通常会保存十个左右的维度外键和多个度量事实，度量事实是事实表的关键所在。在非事实型事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或者说明某些活动的范围。下面举例来进行说明。

第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件，学校需要对学生按学期进行跟踪。维度表包括学期维度、课程维度、系维度、学生维度、注册专业维度和取得学分维度，而事实表是由这些维度的主键组成，事实只有注册数，并且恒为1。这样的事实表可以回答大量关于大学开课注册方面的问题，主要是回答各种情况下的注册数。

第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。通常销售事实表可以回答如促销商品的销售情况，但是对于那些没有销售出去的促销商品没法回答。这时，通过建立促销范围事实表，将商场需要促销的商品单独建立事实表保存。然后，通过这个促销范围事实表和销售事实表即可得出哪些促销商品没有销售出去。这样的促销范围事实表只是用来说明促销活动的范围，其中没有任何事实度量。

事实表中通常要保留度量事实和多个维度外键，度量事实是事实表的关键所在。

非事实表中没有这些度量事实，只有多个维度外键。非事实型事实表通常用来跟踪一些事件或说明某些活动的范围。

第一类非事实型事实表是用来跟踪事件的事实表。例如：学生注册事件。

第二类非事实型事实表是用来说明某些活动范围的事实表。例如：促销范围事实表。

数仓架构为什么要分层

分层可以清晰数据结构，使用时更好的定位和理解方便追踪数据的血缘关系规范数据分层，可以开发一些通用的中间层数据，能够减少极大的重复计算把复杂问题简单化屏蔽原始数据的异常。不必改一次业务就重新接入数据

数据分层思想？

理论上数据分为： *** 作数据层、数据仓库层、数据服务层。可根据需要添加新的层次，满足不同的业务需求。

*** 作数据层ODS

Operate Data Store *** 作数据存储。数据源中的数据经过ETL后装入ODS层。

ODS层数据的来源一般有：业务数据库、日志、抓取等。

数据仓库层DW

根据ODS层中的数据按照主题建立各种数据模型。

DW通常有：DWD、DWB、DWS

DWD: data warehouse detail细节数据层，是业务层和数据仓库的隔离层。

DWB: data warehouse base基础数据层，存储的是客观数据，一般用作于中间层。

DWS: data warehouse service服务数据层，整合汇总分析某个主题域的服务数据。一般是大宽表。

数据服务层/应用层ADS

该层主要提供数据产品和数据分析使用的数据，一般会放在ES、Mysql系统中供线上系统使用

数仓架构进化

经典数仓架构：使用传统工具来建设数仓

离线大数据架构：开始使用大数据工具来替代经典数仓中的传统工具

Lambda架构：在离线大数据架构的基础上，使用流处理技术直接完成实时性较高的指标计算

Kappa：实时处理变成了主要的部分，出现了以实时处理为核心的kappa架构

离线大数据架构

数据源通过离线的方式导入离线数仓中。下游应用根据业务需求选择获取数据的方式

Lambda架构

在离线数仓的基础上增加了实时计算的链路，并对数据源进行流式改造，实时计算去订阅消息队列，并推送到下游的数据服务中去。

Lambda架构问题：同样的需求需要开发两套一样的代码；资源占用增多

Kappa架构

kappa架构可以认为是lambda架构的简化版，移除了lambda架构中的批处理部分。

在kappa架构中，需求修改或者历史数据重新处理都通过上游重放完成

kappa架构最大的问题是流式重新处理历史数据的吞吐能力会低于批处理，但可以通过增加计算资源来弥补

总结

真实场景中，是lambda架构和kappa架构的混合。大部分实时指标通过kappa架构计算，少量关键指标用lambda架构批量计算

随着数据多样性的发展，数据库这种提前规定schema的模式显得力不从心。这时出现了数据湖技术，把原始数据全部缓存到某个大数据存储上，后续分析时根据需求去解析原始数据。简单来说，数据仓库模式是schema on write，数据湖模式是schema on read

OLAP简介

OLAP（On-line Analytical Processing），联机分析处理，其主要的功能在于方便大规模数据分析及统计计算，对决策提供参考和支持。

特点：数据量大、高速响应、灵活交互、多维分析

OLAP分类

存储类型分类

ROLAP（RelationalOLAP）

MOLAP（MultimensionalOLAP）

HOLAP（HybridOLAP）

处理类型分类

MPP架构

搜索引擎架构

预处理架构

开源OLAP解决方案

Persto、SparkSQL、Impala等MPP架构和ROLAP的引擎Druid和Kylin等预处理架构和MOLAP的引擎ES这种搜索引擎架构ClickHouse及IndexR这种列式数据库

OLAP引擎

Presto

Facebook开发的分布式大数据SQL查询引擎，专门进行快速数据分析

特点

可以将多个数据源的数据进行合并，可以跨越整个组织进行分析直接从HDFS读取数据，在使用前不需要大量的ETL *** 作

查询原理

完全基于内存的并行计算

流水线

本地化计算

动态编译执行计划

小心使用内存和数据结构

类BlinkDB的近似查询

GC控制

Druid

Druid是一个用于实时查询和分析的分布式实时处理系统，主要用于广告分析，互联网广告监控、度量和网络监控

特点

快速的交互式查询——Druid的低延迟数据摄取架构允许事件在它们创建后毫秒内可被查询到。高可用性——Druid的数据在系统更新时依然可用，规模的扩大和缩小都不会造成数据丢失；可扩展——Druid已实现每天能够处理数十亿事件和TB级数据。为分析而设计——Druid是为OLAP工作流的探索性分析而构建，它支持各种过滤、聚合和查询

应用场景

需要实时查询分析具有大量数据时，如每天数亿事件的新增、每天数10T数据的增加；需要一个高可用、高容错、高性能数据库时。需要交互式聚合和快速探究大量数据时

Kylin

Kylin是提供与Hadoop之上的SQL查询接口及多维分析能力以支持超大规模数据

BPM是Business Process Management的简称，译为业务流程管理，它是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化工具和方法论，面对经济全球化的竞争压力和各种新技术创新场景下不断变化的用户需求，这种通过诊断、梳理、E化、监控和持续优化业务流程的实践，可以有效提升企业组织力并助力企业赢得市场竞争。

工作流与业务流程参考天翎BPM工作流程平台

·整合快速、拓展灵活，着力构建强大的端到端链接能力；

·掌握流程管理大脑流程引擎核心科技，更适应中国式流程管理；

·提供完善的可视化流程软件开发套件，成熟、稳定、安全。

·传承BPM经典理论指导，专注提升政企组织控制力与执行力；

·天翎17年技术积累和持续打磨的第4代业务流程管理平台；

·融合微服务架构、多租户模式、集群部署等新特性于一体。

架构领先:SpringBoot微服务架构，支持SpringCloud模式，前后端分离

整合强大:获得SAP特别认证，可与金蝶、用友三方专有系统全面对接整合

兼容性强:兼容所有主流浏览器、数据库、应用服务器、 *** 作系统和应用端

性能强劲:支持分布式和集群部署，负载均衡动态调配，支持集团化海量数据与高并发

业务上云:符合PasS云服务特征，开发调试、软件发布均可远程在线完成

中国特色:掌握流程引擎核心科技，特适应中国式流程管理业务模式和 *** 作习惯

落地快速:WeB可视化配置式开发，版本化管理，节省80%以上开发量

安全可靠:银行级加密技术，用户访问、业务 *** 作、数据存储、系统交互，严格的权限控制和日志记录

仅参考

工作流：

根据 WfMC 的定义，工作流（Workflow）就是自动运作的业务过程部分或整体，表现为参与者对文件、信息或任务按照规程采取行动，并令其在参与者之间传递。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。

工作流是针对工作中具有固定程序的常规活动而提出的一个概念。通过将工作活动分解成定义良好的任务、角色、规则和过程来进行执行和监控，达到提高生产组织水平和工作效率的目的。工作流技术为企业更好地实现经营目标提供了先进的手段。

1993年，国际工作流管理联盟（Workflow Management Coalition，WfMC）的成立标志着工作流技术开始进入相对成熟的阶段。为了实现不同工作流产品之间的互 *** 作，WfMC在工作流管理系统的相关术语、体系结构及应用编程接口等方面制定了一系列标准。工作流管理联盟给出的工作流定义是：工作流是指整个或部分经营过程在计算机支持下的全自动或半自动化。在实际情况中可以更广泛地把凡是由计算机软件系统（工作流管理系统）控制其执行的过程都称为工作流。

一个工作流包括一组活动及它们的相互顺序关系，还包括过程及活动的启动和终止条件，以及对每个活动的描述。工作流管理系统指运行在一个或多个工作流引擎上用于定义、实现和管理工作流运行的一套软件系统，它与工作流执行者（人、应用）交互，推进工作流实例的执行，并监控工作流的运行状态。

一、工作流管理：

通常，工作流管理系统指运行在一个或多个称为工作流机的软件上的用于定义、实现和管理工作流运行的一套软件系统，它和工作流执行者（人、应用）交互，推进工作流实例的执行，并监控工作流的运行状态。在这里需要强调指出的是工作流管理系统不是企业的业务系统。在很大程度上，工作流管理系统为企业的业务系统运行提供一个软件支撑环境，非常类似于在单个计算机上的 *** 作系统。只不过工作流管理系统支撑的范围比较大、环境比较复杂而已，所以也有人称工作流管理系统是业务 *** 作系统（BOS － Business Operating System）。在工作流管理系统的支撑下，通过集成具体的业务应用软件和 *** 作人员的界面 *** 作，才能够良好地完成对企业经营过程运行的支持。所以，工作流管理系统在一个企业或部门的经营过程中的应用过程是一个业务应用软件系统的集成与实施过程。

二、工作流管理系统：

工作流管理系统可以用来定义与执行不同覆盖范围（单个工作者、部门、全企业、企业间）、不同时间跨度（分钟、小时、天、月）的经营过程。这完全取决于实际应用背景的需求。按照经营过程以及组成活动的复杂程度的不同，工作流管理系统可以采取许多种实施方式，在不同的实施方式中，所应用的信息技术、通信技术和支撑系统结构会有很大的差别。工作流管理系统的实际运行环境可以是在一个工作组内部或者在全企业的所有业务部门。

三、业务过程：

业务过程（business process）就是活动的集合，这些活动均关联于特定的托付事项（commitment），为过程的产出增值。相对于“工作流”，业务过程是一个更一般化的统称，而工作流这个词，则已经不能仅从字面含义或原理上去理解，它已经被赋予了更深一层的特定含义——专指基于信息技术规划、运作、管理的业务过程。

四、自动与协调:

“自动”（automate）是工作流的一个特征，但这主要是指它自动进行的特征，而不是说没有人的参与。工作流实际上是一个人-电脑协调的混合过程，在一个实际的工作流中，通常总有些步骤是人完成的。协调是工作流管理的一个目标或者特征，这包括了人与人、人与电脑，电脑（软件）之间等多种层面的含义。

五、监察与控制:

监察（Monitoring）与控制（Contorl）是工作流系统的重要功能与特征。这不仅包括对正在发生的业务过程（工作流），还包括它的定义或改变（比如BPR的过程）。这是工作流系统带给我们的明显好处之一。

六、标准化:

作流的概念被明确提出并得到重视的同时，人们就认识到了“标准化”在其中的重要性，有关工作流的标准开发和推广，基本是与“工作流”的开发和推广同步进行的。在这方面目前的权威性机构，是“工作流管理联盟”（Workflow Management Coalition, WfMC）。它成立于1993年8月，目前已拥有 130 余个成员，成员包括工作流产品的供应者、应用者，有关大学和研究机构和个人，是一个国际性的非赢利组织。在最近的投资成员（Funding members）清单中，可以看到诸如 Baan, HP, IBM, Microsoft, Oracle, Peplesoft, SAP AG, Xerox 等机构。

七、工作流与重规划:

从逻辑上，对工作流的关注和研究可以看作是对业务过程重规划（BPR）的一种深化。BPR的观点，要求我们将眼光投向实际业务进行的过程，但这个过程应当是什么样的，怎样分析、构造？工作流就是一个具体的、 *** 作性的答案，它可以令我们从神秘的、难以预测和控制的“头脑风暴式”的“艺术的”业务过程创造，变成解析的、技术的、可控制和预测的工程化过程，如此，才真正体现出 re-engineering 中 engineering 的意义。

工作流与 BPR 的概念，已经被几乎所有的研究者联系在一起研究和应用。在这个领域有一个非常活跃的组织，即国际工作流与重规划协会（ Workflow And Reengineering International Association, WARIA）。

八、工作流与企业工程:

无论从理论、方法上，还是对象、内容上，我们都有理由将“工作流”看作是企业工程的一部分。实际上，已有的关于工作流体系的描述，本身就是一个通用的业务模型框架。仅仅囿于工作流是不够的，必须对整个体系的目标及所有相关要素综合考虑——这正是企业工程。

九、工作流与IT应用体系:

与以往已经被采用的企业 IT 应用体系，例如 MRPII 或 ERP 相比，WFMS是一个相当重要的里程碑。（ERP的概念并不确定，我这里仅指其基本或较早期的含义而言）。从用户的角度，WFMS带来（或将要带来）的变化是极其强烈的，甚至可以形容为一种用户“梦想”的实现。

在一些老的“模块化”的产品中，系统的设计是通常是基于任务分割的，作业项目之间是分裂的。面向对象的技术，并不能直接解决这个的问题，相反，往往使系统变得更加混乱和琐碎。从 *** 作上，典型地，我们必须不断地在层次结构的功能表（比如下拉菜单）或对象之间“进进退退”，或者在“神出鬼没”的对象以及相关菜单中捉迷藏。

工作流管理系统是一个真正的“人-机”系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到电脑针对自己列出的“任务清单”，跟踪每一项任务的状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这样，用户的任务分派和任务的完成状态，可以被最大程度地电脑化和受到控制。

现在的典型工作流产品是客户-服务软件。而日益增长的重要途径是通过万维网界面，它可以令客户或远程的职员更好地参与。工作流的定义经常是借助于图形化工具，依照业务过程实例的情况定义相应工作的安排

OA(办公自动化)： 引自肖淑男 2001-2-20

通常，OA 就是办公自动化，英文Office Automation的缩写。通过流程或特定环节与日常事务联系在一起，使公文在流转、审批、发布等方面提高效率，实现办公管理规范化和信息规范化，降低企业运行成本的一套系统的统称。

多年来，OA尚无一个确切的定义，人们对OA的看法和理解各有不同。笔者认为：OA本身就不是一个有确定界定的概念，它是一个过程、一种境界。它随技术的发展而发展，随人们办公方式和习惯以及管理思想的变化而变化。在技术发展过程中的每一个阶段，人们给OA赋予了不同的内容和新的想象，技术与管理的进步给OA打下了每一步发展的历史烙印。同时，不同行业、不同层次的人对OA的看法和理解也各有不同。也许正是OA这种变化和发展的特点使之成为30多年来常新不衰的话题。

现在有一种较普遍的偏见：认为OA仅仅是诸如公文流转、收发文管理、档案管理、会议安排、文献检索、电子表格、电子邮件等等这些非结构化数据的处理和交换过程，面向的用户群也只是机关办公室或企业的职能部门、文秘部门。其实，今天看来，OA应有更丰富的内容和层面，更广泛的用户群。以下是笔者对OA在功能上以及所涉及的技术范畴的肤浅理解，愿与同行商榷。

功能方面：广义面言，OA应该是一个企业除了生产控制之外的一切信息处理与管理的集合。它面向不同层次的使用者，便有不同的功能表现：

对于企业高层领导而言，OA是决策支持系统（DSS）。OA运用科学的数学模型，结合企业内部／外部的信息为条件，为企业领导提供决策参考和依据；

对于中层管理者而言：OA是信息管理系统（IMS），OA利用业务各环节提供的基础“数据”，提炼出有用的管理“信息”，把握业务进程，降低经营风险，提高经营效率；

对于普通员工而言：OA是事务／业务处理系统。OA为办公室人员提供良好的办公手段和环境，使之准确、高效，愉快地工作。

技术范畴：OA是计算机技术在办公业务中的合理应用。计算机技术是OA的前提。如果脱离计算机技术面阔谈OA，无异于痴人说梦。没有计算机技术，OA便成无源之水、无本之木。计算机对信息的存储与处理能力极大地改变了人们的办公方式，提高了工作效率。如：要建立决策支持系统，则需要数据仓库 、OLAP等技术；要建立信息管理系统，则要有数据库、程序设计语言等技术；要建立事务／业务处理系统，则离不开数据库、设计良好的人机界面和工作流控制、OLTP等技术。

OA是利用通信技术来实现人与机器、机器与机器及人与人的交流。通信技术是OA的基础。现代办公室不再是孤军奋战，而是一个团队的协同工作，团队中成员之间的协调、合作离不开通信技术；现代办公室也不再是闭门造车，企业需要与外界广泛的信息交流，这更离不开通信技术。没有通信技术的支持，OA便成空中楼阁。

OA是科学的管理思想在先进的技术手段下的物化。科学的管理思想是实现OA的核心。计算机技术和通信技术仅仅是为实现OA打下了基础，提供了可能。要真正实现OA，还需物化人类思维中科学管理的内容。正如仅有优质的画笔、画板、颜料而没有达芬奇，就不会有蒙娜尼莎的微笑一样。不体现人类管理智慧，就不会有真正的OA，如果有，也只是技术的堆砌和摆设。

由此而知，OA是计算机技术、通信技术与科学的管理思想完美结合的一种境界和理想。我们一直在为实现OA而努力，但我们的成果仅仅是在某些环节、某些方面、部分地实现了OA的功能，与真正的OA尚有差距，差距的根本在于应用系统对管理思想的实现方面。一等一科技为您解答！！

以上就是关于基于事例处理的工程项目工作流管理全部的内容，包括:基于事例处理的工程项目工作流管理、求一篇网站数据库设计论文、关于数据库的问题，画ERD图等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！