保险数据仓库建模

⑴ 数据仓库数据建模的几种思路

数据仓库接典型的两种数据仓库建模的理论是维度建模和基于主题域的实体关系建模，这两种方式分别以Kimball和Immon两位大师为代表。维度建模以数据分析需求为驱动，倡导总线架构：一致的事实和一致的维度，这种数据模型易于用户理解和数据分析操作。基于主题域的实体关系建模以源系统数据为驱动，整合企业的所有数据，站在企业级的高度对数据进行抽象，整合，采用3NF的实体关系理论建模，这种数据建模方式以更为抽象的方式尝试建立一个相对稳定的数据模型，并能描述企业级的数据关系。在工业界往往把两种方式结合起来运用数据仓库的不同数据层次结构中。
我们上周主要是针对采用基于主题域的实体关系建模中数据整合的方式进行较为深入的讨论，讨论了以下三种思路：
以属性聚集的方式同一主题域中不同实体的属性。比如对于会员、公司、客户等等实体对象我们都有地址属性信息、名称标识属性信息等等，这种思路就是把属性内聚性高的字段整合在一起，并把不同的属性打上类型标识以树表的形式存放。它的优点是：第一，模型稳定性好，外围系统变化了字段，只需要添加不同的类型，不需要进行表结构的变更；第二，减少大量冗余记历史数据。它的缺点是：第一，丢失了很多实体的属性标识信息，我们从模型上将看不到一个会员究竟有哪些地址属性，只能通过查询类型代码才能获取这些信息；第二，它极度的膨胀数据表的记录数，因为它采用竖表的形式存放；第三，应用起来很难，效率是一个大问题，因为我们往往要使用一个实体的多个字段，就会有很多join操作和竖转横的操作。第四：属性聚集也是一件比较难操作的过程，应为这是一个抽象的过程，对建模人员的业务背景知识和抽象能力都提出了很高的要求；第五：虽然减少了冗余的记历史数据，但是记历史的操作也较为复杂。
采用面向对象建模的方式，抽象不同实体的共同属性，然后再一步步采用继承、组合等面向对象的思想具体化实体。他的优点是模型模型概念比较清晰，缺点也是模型相对不是很稳定，整合后的数据的后续应该也面临重新组合的问题。
贴源的建模方式：
采用基本保持源系统的方式进行建模，重点放在数据的标准化，一致化，和数据业务意义的梳理。这种做法和我们目前数据仓库的做法比较类似。它具有实施比较容易，快速实现，前台可以直接使用数据；缺点是整合度不高，模型不稳定。
模型终究是为数据分析应用服务的，具体采用什么方式建模需要根据实际业务特点和源系统的特点决定。阿里巴巴的源系统具有变化快，数据分析应该变化快的特点，响应速度也要快的特点，而且我们要求不同系统之间整合的需求并不是很大，往往深度的数据整合带来的是应用上的不方便。因此，我个人觉得采用贴源的方式是当前更优的方案。

⑵ 保险公司如何使用数据仓库增加利润

目前保险业的竞争愈演愈烈，综合竞争力，特别是对大数据和变现能力的提升对于保险企业至关重要。因此，保险公司的数据仓库建设相当必要和重要。
数据仓库在保险业主要应用有CRM和DSS，另外还有RM，其实变现提升利润更主要还是应用在业务系统，即CRM上。对客户信息、客户关系等大数据分析，能够有效提高交易量和成交率。

⑶ 数据仓库建模，星型模型大致了解，就是事实表对应许多维表；对雪花型模型就不是很理解了

详细和你说一下星型模型和雪花模型
星型模式 vs 雪花模型多维数据建模以直观的方式组织数据，并支持高性能的数据访问。每一个多维数据模型由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。多维模型最常见的是星形模式。在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。在星型的基础上，发展出雪花模式，下面就二者的特点做比较。 星型模式位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。每个指标实体代表一系列相关事实，完成一项指定的功能。位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。每个维表有自己的属性，维表和事实表通过关键字相关联。星形模式虽然是一个关系模型，但是它不是一个规范化的模型。在星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中的关系模式的基本区别。使用星形模式主要有两方面的原因:提高查询的效率。采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;便于用户理解。对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。总结：非正规化；多维数据集中的每一个维度都与事实表连接（通过主键和外键）；不存在渐变维度；有冗余数据；查询效率可能会比较高；不用过多考虑正规化因素，设计维护较为简单。
雪花模式 在实际应用中，随着事实表和维表的增加和变化，星形模式会产生多种衍生模式，包括星系模式、星座模式、二级维表和雪花模式。雪花模式是对星形模式维表的进一步层次化，将某些维表扩展成事实表，这样既可以应付不同级别用户的查询，又可以将源数据通过层次间的联系向上综合，最大限度地减少数据存储量，因而提高了查询功能。雪花模式的维度表是基于范式理论的，因此是界于第三范式和星形模式之间的一种设计模式，通常是部分数据组织采用第三范式的规范结构，部分数据组织采用星形模式的事实表和维表结构。在某些情况下，雪花模式的形成是由于星形模式在组织数据时，为减少维表层次和处理多对多关系而对数据表进行规范化处理后形成的。雪花模式的优点是:在一定程度上减少了存储空间;规范化的结构更容易更新和维护。同样雪花模式也存在不少缺点:雪花模式比较复杂，用户不容易理解;浏览内容相对困难;额外的连接将使查询性能下降。在数据仓库中，通常不推荐“雪花化”。因为在数据仓库中，查询性能相对OLTP系统来说更加被重视，而雪花模式会降低数据仓库系统的性能。总结：正规化；数据冗余少；有些数据需要连接才能获取，可能效率较低；规范化操作较复杂，导致设计及后期维护复杂；实际应用中，可以采取上述两种模型的混合体：如：中间层使用雪花结构以降低数据冗余度，数据集市部分采用星型以方便数据提取及和分析。
有时候规范化和效率是一组矛盾。一般我们会采取牺牲空间（规范化）来换取好的性能，把尽可能多的维度信息存在一张“大表”里面是最快的。通常会视情况而定，采取折中的策略。
星型有时会造成数据大量冗余，并且很有可能将事实表变的及其臃肿（上百万条数据×上百个维度）。
每次遇到需要更新维度成员的情况时，都必须连事实表也同时更新。
而雪花型，有时只需要更新雪花维度中的一层即可，无需更改庞大的事实表。
具体问题具体分析，如时间维度，年，季就没必要做雪花，而涉及到产品和产品的分类，如果分类信息也是我们需要分析的信息，那么，我肯定是建关于分类的查找表，也就是采用雪花模式

雪花型结构是一种正规化结构，他取除了数据仓库中的冗余数据。比如有一张销售事实表，然后有一张产品维度表与之相连，然后有一张产品类别维度表与产品维度表连。这种结构就是雪花型结构。雪花型结构取除了数据冗余，所以有些统计就需要做连接才能产生，所以效率不一定有星型架构高。正规化也是一种比较复杂的过程，相应数据库结构设计、数据的ETL、以及后期的维护都要复杂一些。
星型架构是一种非正规化的结构，多维数据集中的每一个维度都与事实表相连接，不存在渐变维度，所以数据有一定的冗余，正因为数据的冗余所以很多统计查询不需要做外部的连接所以一般情况下效率比雪花型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。
虽然两种结构有一定差别，我个人认为没有好坏之分，最主要的还是看项目的需求，看业务逻辑。

⑷ 数据仓库的建模,很多公司都要用到这个，这个具体是用来做什么的啊

数据仓库模型的特点

对于传统的OLTP系统，我们总是按照应用来建立它的模型，换言之，OLTP系统是面向应用的。而数据仓库则一般按照主题 (Subject)来建模，它是面向主题的。何谓应用?何谓主题?让我们来看一个简单的例子。在银行中，一般都有对私 (个人储蓄)、对公 (企业储蓄)、信用卡等多种业务系统，它们都是面向应用的，所支持的交易类型简单而且固定。由于实施的先后等原因，这些系统可能运行在不同的平台上，相互之间没有什么关系，各系统之间的数据存在冗余。比如每个系统中都会有客户的数据，当针对银行建立其数据仓库应用时，要把上述生产系统中的数据转换到数据仓库中来。从整个银行的角度来看，其数据模型不再面向个别应用，而是面向整个银行的主题，比如客户、产品、渠道等。因此，各个生产系统中与客户、产品、渠道等相关的信息将分别转换到数据仓库中相应的主题中，从而在整个银行的业务界面上提供一个一致的信息视图。
数据仓库的建模方法

逻辑建模是数据仓库实施中的重要一环，因为它能直接反映出业务部门的需求，同时对系统的物理实施有着重要的指导作用。目前较常用的两种建模方法是所谓的第三范式 (3NF，即 Third Normal Form)和星型模式 (Star-Schema)，我们将重点讨论两种方法的特点和它们在数据仓库系统中的适用场合。

⑸ 数据仓库有哪些模型举例说明

1、星型模型
星型模型是一种由一点向外辐射的建模范例，中间有一单一对象沿半径向外连接到多个对象。星型模型反映了最终用户对商务查询的看法:销售事实、赔偿、付款和货物的托运都用一维或多维描述(按月、产品、地理位置)。星型模型中心的对象称为“事实表”，与之相连的对象称为“维表”。对事实表的查询就是获取指向维表的指针表，当对事实表的查询与对维表的查询结合在一起时，就可以检索大量的信息。通过联合，维表可以对查找标准细剖和聚集。
2、雪花模型
雪花模型是对星型模型的扩展，每一个点都沿半径向外连接到多个点.雪花模型对星型的维表进一步标准化，它的优点是通过最大限度的减少数据存储量以及把较小的标准化表(而不是大的非标准化表)联合在一起来改善查询性能。化及维的较低的粒度，雪花模型增加了应用程序的灵活性。
3、混合模型
混合模型是星型模型和雪花模型的一种折衷模式，其中星型模型由事实表和标准化的维表组成，雪花模型的所有维表都进行了标准化。在混合模型中，只有最大的维表才进行标准化，这些表一般包含一列列完全标准化的(重复的)数据。

⑹ 数据仓库的数据模型

1. 星型模式

星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布；

星座模型

⑺ 数据仓库建模 etl 哪个方向好

这几个职位都是跟数据有关的工作。
BI 是商业智能，职位包括etl,数据仓库，数据展示工作。
数据仓库，是按设定好的一种数据库模型
ETL，负责清洗原始数据的一个过程，清洗完之后将数据加载至数据仓库。
大数据开发，数据量较大，上千万乃至亿级的数据量开发

⑻ 初学者的数据仓库建模以后在access里建表的问题~~各位大虾帮忙啊~~

看在你给了5分的份上 第一个问题:时间必须单独建表 产品单独建 工厂 商城 也可以单独建。但是你要注意，维度表单独建是挺好，但是单独建多了也不好 第二个问题和第三个问题是一个问题 事实表（数据仓库）是根据事实表（这里的事实指业务数据库）与维度联系来的
先回答这些 不明白再问

⑼ 数据仓库的建模划分

数据仓库的数据建模大致分为四个阶段：
1.业务建模，这部分建模工作，主要包含以下几个部分： 划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。 深入了解各个业务部门的内具体业务流程并将其程序化。 提出修改和改进业务部门工作流程的方法并程序化。 数据建模的范围界定，整个数据仓库项目的目标和阶段划分。 2.领域概念建模，这部分得建模工作，主要包含以下几个部分： 抽取关键业务概念，并将之抽象化。 将业务概念分组，按照业务主线聚合类似的分组概念。 细化分组概念，理清分组概念内的业务流程并抽象化。 理清分组概念之间的关联，形成完整的领域概念模型。 3.逻辑建模，这部分的建模工作，主要包含以下几个部分： 业务概念实体化，并考虑其具体的属性 事件实体化，并考虑其属性内容 说明实体化，并考虑其属性内容 4.物理建模，这部分得建模工作，主要包含以下几个部分： 针对特定物理化平台，做出相应的技术调整 针对模型的性能考虑，对特定平台作出相应的调整 针对管理的需要，结合特定的平台，做出相应的调整 生成最后的执行脚本，并完善之。