数据仓库建模
❶ 请问数据仓库都用什么建立
数据仓库是抄为了管理袭数据，主要是思想。
具体实施的工具就是为了解决问题而选取了
比如异构/不同源数据的数据抽取问题，要用到etl，可能会用工具 或者自己写程序，看情况而定‘
数据仓库的模型建设，要用到erwin等建模工具；
数据的存放一般是借助关系数据库来实现，那么会用到oracle之类。不过现在已经开始慢慢摒弃传统关系数据库了，借助一些No sql平台，比如hadoop上的hive之类。
不过无论用什么工具，一定要记住，数据仓库的思想是不变的，就是管理数据、把数据的价值通过有效地管理而展现出来，不经管理的数据就是一堆没有提炼的金矿，看着很值钱，直接狗屁用没有。
❷ 数据仓库数据建模的几种思路
数据仓库接典型的两种数据仓库建模的理论是维度建模和基于主题域的实体关系建模，这两种方式分别以Kimball和Immon两位大师为代表。维度建模以数据分析需求为驱动，倡导总线架构：一致的事实和一致的维度，这种数据模型易于用户理解和数据分析操作。基于主题域的实体关系建模以源系统数据为驱动，整合企业的所有数据，站在企业级的高度对数据进行抽象，整合，采用3NF的实体关系理论建模，这种数据建模方式以更为抽象的方式尝试建立一个相对稳定的数据模型，并能描述企业级的数据关系。在工业界往往把两种方式结合起来运用数据仓库的不同数据层次结构中。 我们上周主要是针对采用基于主题域的实体关系建模中数据整合的方式进行较为深入的讨论，讨论了以下三种思路： 以属性聚集的方式同一主题域中不同实体的属性。比如对于会员、公司、客户等等实体对象我们都有地址属性信息、名称标识属性信息等等，这种思路就是把属性内聚性高的字段整合在一起，并把不同的属性打上类型标识以树表的形式存放。它的优点是：第一，模型稳定性好，外围系统变化了字段，只需要添加不同的类型，不需要进行表结构的变更；第二，减少大量冗余记历史数据。它的缺点是：第一，丢失了很多实体的属性标识信息，我们从模型上将看不到一个会员究竟有哪些地址属性，只能通过查询类型代码才能获取这些信息；第二，它极度的膨胀数据表的记录数，因为它采用竖表的形式存放；第三，应用起来很难，效率是一个大问题，因为我们往往要使用一个实体的多个字段，就会有很多join操作和竖转横的操作。第四：属性聚集也是一件比较难操作的过程，应为这是一个抽象的过程，对建模人员的业务背景知识和抽象能力都提出了很高的要求；第五：虽然减少了冗余的记历史数据，但是记历史的操作也较为复杂。 采用面向对象建模的方式，抽象不同实体的共同属性，然后再一步步采用继承、组合等面向对象的思想具体化实体。他的优点是模型模型概念比较清晰，缺点也是模型相对不是很稳定，整合后的数据的后续应该也面临重新组合的问题。 贴源的建模方式： 采用基本保持源系统的方式进行建模，重点放在数据的标准化，一致化，和数据业务意义的梳理。这种做法和我们目前数据仓库的做法比较类似。它具有实施比较容易，快速实现，前台可以直接使用数据；缺点是整合度不高，模型不稳定。 模型终究是为数据分析应用服务的，具体采用什么方式建模需要根据实际业务特点和源系统的特点决定。阿里巴巴的源系统具有变化快，数据分析应该变化快的特点，响应速度也要快的特点，而且我们要求不同系统之间整合的需求并不是很大，往往深度的数据整合带来的是应用上的不方便。因此，我个人觉得采用贴源的方式是当前更优的方案。
❸ 数据仓库建模，星型模型大致了解，就是事实表对应许多维表；对雪花型模型就不是很理解了
详细和你说一下星型模型和雪花模型
星型模式 vs 雪花模型多维数据建模以直观的方式组织数据，并支持高性能的数据访问。每一个多维数据模型由多个多维数据模式表示，每一个多维数据模式都是由一个事实表和一组维表组成的。多维模型最常见的是星形模式。在星形模式中，事实表居中，多个维表呈辐射状分布于其四周，并与事实表连接。在星型的基础上，发展出雪花模式，下面就二者的特点做比较。 星型模式位于星形中心的实体是指标实体，是用户最关心的基本实体和查询活动的中心，为数据仓库的查询活动提供定量数据。每个指标实体代表一系列相关事实，完成一项指定的功能。位于星形图星角上的实体是维度实体，其作用是限制用户的查询结果，将数据过滤使得从指标实体查询返回较少的行，从而缩小访问范围。每个维表有自己的属性，维表和事实表通过关键字相关联。星形模式虽然是一个关系模型，但是它不是一个规范化的模型。在星形模式中，维度表被故意地非规范化了，这是星形模式与OLTP系统中的关系模式的基本区别。使用星形模式主要有两方面的原因:提高查询的效率。采用星形模式设计的数据仓库的优点是由于数据的组织已经过预处理，主要数据都在庞大的事实表中,所以只要扫描事实表就可以进行查询，而不必把多个庞大的表联接起来，查询访问效率较高。同时由于维表一般都很小,甚至可以放在高速缓存中,与事实表作连接时其速度较快;便于用户理解。对于非计算机专业的用户而言，星形模式比较直观，通过分析星形模式，很容易组合出各种查询。总结：非正规化；多维数据集中的每一个维度都与事实表连接（通过主键和外键）；不存在渐变维度；有冗余数据；查询效率可能会比较高；不用过多考虑正规化因素，设计维护较为简单。
雪花模式 在实际应用中，随着事实表和维表的增加和变化，星形模式会产生多种衍生模式，包括星系模式、星座模式、二级维表和雪花模式。雪花模式是对星形模式维表的进一步层次化，将某些维表扩展成事实表，这样既可以应付不同级别用户的查询，又可以将源数据通过层次间的联系向上综合，最大限度地减少数据存储量，因而提高了查询功能。雪花模式的维度表是基于范式理论的，因此是界于第三范式和星形模式之间的一种设计模式，通常是部分数据组织采用第三范式的规范结构，部分数据组织采用星形模式的事实表和维表结构。在某些情况下，雪花模式的形成是由于星形模式在组织数据时，为减少维表层次和处理多对多关系而对数据表进行规范化处理后形成的。雪花模式的优点是:在一定程度上减少了存储空间;规范化的结构更容易更新和维护。同样雪花模式也存在不少缺点:雪花模式比较复杂，用户不容易理解;浏览内容相对困难;额外的连接将使查询性能下降。在数据仓库中，通常不推荐“雪花化”。因为在数据仓库中，查询性能相对OLTP系统来说更加被重视，而雪花模式会降低数据仓库系统的性能。总结：正规化；数据冗余少；有些数据需要连接才能获取，可能效率较低；规范化操作较复杂，导致设计及后期维护复杂；实际应用中，可以采取上述两种模型的混合体：如：中间层使用雪花结构以降低数据冗余度，数据集市部分采用星型以方便数据提取及和分析。
有时候规范化和效率是一组矛盾。一般我们会采取牺牲空间（规范化）来换取好的性能，把尽可能多的维度信息存在一张“大表”里面是最快的。通常会视情况而定，采取折中的策略。
星型有时会造成数据大量冗余，并且很有可能将事实表变的及其臃肿（上百万条数据×上百个维度）。
每次遇到需要更新维度成员的情况时，都必须连事实表也同时更新。
而雪花型，有时只需要更新雪花维度中的一层即可，无需更改庞大的事实表。
具体问题具体分析，如时间维度，年，季就没必要做雪花，而涉及到产品和产品的分类，如果分类信息也是我们需要分析的信息，那么，我肯定是建关于分类的查找表，也就是采用雪花模式
雪花型结构是一种正规化结构，他取除了数据仓库中的冗余数据。比如有一张销售事实表，然后有一张产品维度表与之相连，然后有一张产品类别维度表与产品维度表连。这种结构就是雪花型结构。雪花型结构取除了数据冗余，所以有些统计就需要做连接才能产生，所以效率不一定有星型架构高。正规化也是一种比较复杂的过程，相应数据库结构设计、数据的ETL、以及后期的维护都要复杂一些。
星型架构是一种非正规化的结构，多维数据集中的每一个维度都与事实表相连接，不存在渐变维度，所以数据有一定的冗余，正因为数据的冗余所以很多统计查询不需要做外部的连接所以一般情况下效率比雪花型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。
虽然两种结构有一定差别，我个人认为没有好坏之分，最主要的还是看项目的需求，看业务逻辑。
❹ 数据仓库的模型有哪些
1、星型模型
星型模型是一种由一点向外辐射的建模范例，中间有一单一对象沿半径向外连接到多个对象。星型模型反映了最终用户对商务查询的看法:销售事实、赔偿、付款和货物的托运都用一维或多维描述(按月、产品、地理位置)。星型模型中心的对象称为“事实表”，与之相连的对象称为“维表”。对事实表的查询就是获取指向维表的指针表，当对事实表的查询与对维表的查询结合在一起时，就可以检索大量的信息。通过联合，维表可以对查找标准细剖和聚集。
2、雪花模型
雪花模型是对星型模型的扩展，每一个点都沿半径向外连接到多个点.雪花模型对星型的维表进一步标准化，它的优点是通过最大限度的减少数据存储量以及把较小的标准化表(而不是大的非标准化表)联合在一起来改善查询性能。化及维的较低的粒度，雪花模型增加了应用程序的灵活性。
3、混合模型
混合模型是星型模型和雪花模型的一种折衷模式，其中星型模型由事实表和标准化的维表组成，雪花模型的所有维表都进行了标准化。在混合模型中，只有最大的维表才进行标准化，这些表一般包含一列列完全标准化的(重复的)数据。
❺ 数据建模的分析方法有哪些并写出他们的大概介绍
从目前的数据库及数据仓库建模方法来说，主要分为四类。
第一类是大家最为熟悉的关系数据库的三范式建模，通常我们将三范式建模方法用于建立各种操作型数据库系统。
第二类是Inmon提倡的三范式数据仓库建模，它和操作型数据库系统的三范式建模在侧重点上有些不同。Inmon的数据仓库建模方法分为三层，第一层是实体关系层，也即企业的业务数据模型层，在这一层上和企业的操作型数据库系统建模方法是相同的；第二层是数据项集层，在这一层的建模方法根据数据的产生频率及访问频率等因素与企业的操作型数据库系统的建模方法产生了不同；第三层物理层是第二层的具体实现。
第三类是Kimball提倡的数据仓库的维度建模，我们一般也称之为星型结构建模，有时也加入一些雪花模型在里面。维度建模是一种面向用户需求的、容易理解的、访问效率高的建模方法，也是笔者比较喜欢的一种建模方式。
第四类是更为灵活的一种建模方式，通常用于后台的数据准备区，建模的方式不拘一格，以能满足需要为目的，建好的表不对用户提供接口，多为临时表。
下面简单谈谈第四类建模方法的一些的经验。
数据准备区有一个最大的特点，就是不会直接面对用户，所以对数据准备区中的表进行操作的人只有ETL工程师。ETL工程师可以自己来决定表中数据的范围和数据的生命周期。下面举两个例子：
1）数据范围小的临时表
当需要整合或清洗的数据量过大时，我们可以建立同样结构的临时表，在临时表中只保留我们需要处理的部分数据。这样，不论是更新还是对表中某些项的计算都会效率提高很多。处理好的数据发送入准备加载到数据仓库中的表中，最后一次性加载入数据仓库。
2）带有冗余字段的临时表
由于数据准备区中的表只有自己使用，所以建立冗余字段可以起到很好的作用而不用承担风险。
举例来说，笔者在项目中曾遇到这样的需求，客户表{客户ID，客户净扣值}，债项表{债项ID，客户ID，债项余额，债项净扣值}，即客户和债项是一对多的关系。其中，客户净扣值和债项余额已知，需要计算债项净扣值。计算的规则是按债项余额的比例分配客户的净扣值。这时，我们可以给两个表增加几个冗余字段，如客户表{客户ID，客户净扣值，客户余额}，债项表{债项ID，客户ID，债项余额，债项净扣值，客户余额，客户净扣值}。这样通过三条SQL就可以直接完成整个计算过程。将债项余额汇总到客户余额，将客户余额和客户净扣值冗余到债项表中，在债项表中通过（债项余额×客户净扣值/客户余额）公式即可直接计算处债项净扣值。
另外还有很多大家可以发挥的建表方式，如不需要主键的临时表等等。总结来说，正因为数据准备区是不对用户提供接口的，所以我们一定要利用好这一点，以给我们的数据处理工作带来最大的便利为目的来进行数据准备区的表设计。