精华内容
下载资源
问答
  • 数据仓库 维度建模

    2019-02-12 11:36:03
     本文将详细介绍数据仓库维度建模技术,并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系:规范化数据仓库,维度建模数据仓库,以及独立数据集市。   维度建模的基本概念  ...

    数据仓库与数据集市建模

    前言

            数据仓库建模包含了几种数据建模技术,除了之前在数据库系列中介绍过的ER建模关系建模,还包括专门针对数据仓库的维度建模技术。

            本文将详细介绍数据仓库维度建模技术,并重点讨论三种基于ER建模/关系建模/维度建模的数据仓库总体建模体系:规范化数据仓库,维度建模数据仓库,以及独立数据集市。

     

    维度建模的基本概念

            维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。

            它本身属于一种关系建模方法,但和之前在操作型数据库中介绍的关系建模方法相比增加了两个概念:

            1. 维度表(dimension)

            表示对分析主题所属类型的描述。比如"昨天早上张三在京东花费200元购买了一个皮包"。那么以购买为主题进行分析,可从这段信息中提取三个维度:时间维度(昨天早上),地点维度(京东), 商品维度(皮包)。通常来说维度表信息比较固定,且数据量小。

            2. 事实表(fact table)

            表示对分析主题的度量。比如上面那个例子中,200元就是事实信息。事实表包含了与各维度表相关联的外码,并通过JOIN方式与维度表关联。事实表的度量通常是数值类型,且记录数会不断增加,表规模迅速增长。

            注:在数据仓库中不需要严格遵守规范化设计原则(具体原因请看上篇)。本文示例中的主码,外码均只表示一种对应关系,此处特别说明

     

    维度建模的三种模式

            1. 星形模式

            星形模式(Star Schema)是最常用的维度建模方式,下图展示了使用星形模式进行维度建模的关系结构:

            可以看出,星形模式的维度建模由一个事实表和一组维表成,且具有以下特点:

                    a. 维表只和事实表关联,维表之间没有关联;

                    b. 每个维表的主码为单列,且该主码放置在事实表中,作为两边连接的外码;

                    c. 以事实表为核心,维表围绕核心呈星形分布;

            2. 雪花模式

            雪花模式(Snowflake Schema)是对星形模式的扩展,每个维表可继续向外连接多个子维表。下图为使用雪花模式进行维度建模的关系结构:

            星形模式中的维表相对雪花模式来说要大,而且不满足规范化设计。雪花模型相当于将星形模式的大维表拆分成小维表,满足了规范化设计。然而这种模式在实际应用中很少见,因为这样做会导致开发难度增大,而数据冗余问题在数据仓库里并不严重。

            3. 星座模式

            星座模式(Fact Constellations Schema)也是星型模式的扩展。基于这种思想就有了星座模式:

     

            前面介绍的两种维度建模方法都是多维表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维表也可能被多个事实表用到。在业务发展后期,绝大部分维度建模都采用的是星座模式。

            4. 三种模式对比

            归纳一下,星形模式/雪花模式/星座模式的关系如下图所示:

            雪花模式是将星型模式的维表进一步划分,使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。本文后面部分将具体讲到这几种模式的使用,请读者结合实例体会。

     

    实例:零售公司销售主题的维度建模

            在进行维度建模前,首先要了解用户需求。而笔者在数据库系列的第一篇就讲过,ER建模是当前收集和可视化需求的最佳技术。因此假定和某零售公司进行多次需求PK后,得到以下ER图:

            随后可利用建模工具将ER图直接映射到关系图: 

            需求搜集完毕后,便可进行维度建模了。本例采用星形模型维度建模。但不论采取何种模式,维度建模的关键在于明确下面四个问题:

            1. 哪些维度对主题分析有用?

            本例中,根据产品(PRODUCT)、顾客(CUSTOMER)、商店(STORE)、日期(DATE)对销售额进行分析是非常有帮助的;

            2. 如何使用现有数据生成维表?

                    a. 维度PRODUCT可由关系PRODUCT,关系VENDOR,关系CATEGORY连接得到;

                    b. 维度CUSTOMER和关系CUSTOMER相同;

                    c. 维度STORE可由关系STROE和关系REGION连接得到;

                    d. 维度CALENDAR由关系SALESTRANSACTION中的TDate列分离得到;

            3. 用什么指标来"度量"主题?

            本例的主题是销售,而销量和销售额这两个指标最能直观反映销售情况;

            4. 如何使用现有数据生成事实表?

            销量和销售额信息可以由关系SALESTRANSACTION和关系SOLDVIA,关系PRODUCT连接得到;

            明确这四个问题后,便能轻松完成维度建模:

            细心的读者会发现三个问题:1. 维表不满足规范化设计(不满足3NF);2. 事实表也不满足规范化设计(1NF都不满足); 3. 维度建模中各维度的主码由***ID变成***Key;

            对于前两个问题,由于当前建模环境是数据仓库,而没有更新操作,所以不需要严格做规范化设计来消除冗余避免更新异常。

            因此虽然可以以雪花模型进行维度建模,如下所示: 

            但这样会加大查询人员负担:每次查询都涉及到太多表了。因此在实际应用中,雪花模型仅是一种理论上的模型。星座模型则出现在"维度建模数据仓库"中,本文后面将会讲到。

            对于第三个问题,***Key这样的字段被称为代理码(surrogate key),它是一个通过自动分配整数生成的主码,没有任何其他意义。使用它主要是为了能够处理"缓慢变化的维度",本文后面会仔细分析这个问题,这里不纠结。

     

    更多可能的事实属性

            除了对应到维度的外码和度量属性,事实表中还常常考虑另外两个属性:事务标识码(transaction identifier)和事务时间(transaction time)。

            事务标识码通常被命名为TID,其意义就是各种订单号,事务编号...... 为什么将这个属性放到事实表而不是维表中呢?一个主要原因是它的数量级太大了,这样每次查询都会耗费很多资源来Join。这种将某些逻辑意义上的维度放到事实表里的做法被称为退化维度(degenerate dimension)。

            将事务时间维度放到事实表中的考虑也是出于相同考虑。然而这么设计又一次"逆规范化"了:事务标识码非主码却决定事务标识时间,显然违背了3NF。但现在我们是为数据仓库建模,所以这样做是OK的。另外在分布式的数据仓库中,这个字段十分重要。因为事实表的数量级非常大,Hive或者Spark SQL这类分布式数据仓库工具都会对这些数据进行分区。任何成熟的分布式计算平台中都应禁止开发人员建立非分区事实表,并默认分区字段为(当天)日期。

     

    经典星座模型

            前文已经讲过,有多个事实表的维度模型被称为星座模型。星座模型主要有以下两大作用:共享维度和设置细节/聚集事实表。下面分别对这两种情况进行分析:

            1. 共享维度

            以前文提到的零售公司为例,假如该公司质量监管部门希望用分析销售主题同样的方法分析劣质产品,那么此时不需要重新维度建模,只需往模型里加入一个新的劣质产品事实表。之后新的数据仓库维度建模结果如下:

            2. 细节/聚集事实表

            细节事实表(detailed fact tables)中每条记录表示单一事实,而聚集事实表(aggregated fact tables)中每条记录则聚合了多条事实。从表的字段上看,细节事实表通常有设置TID属性,而聚集事实表则无。

            两种事实表各有优缺点,细节事实表查询灵活但是响应速度相对慢,而聚集事实表虽然提高了查询速度,但使查询功能受到一定限制。一个常见的做法是使用星座模型同时设置两种事实表(可含多个聚集事实表)。这种设计方法中,聚集事实表使用和细节事实表细节事实表的维度。如下维度建模方法采用星座模型综合了细节事实表和两种聚集事实表:

     

    缓慢变化维度问题

            虽然,维表的数据比事实表更稳定。但不论如何维度在某些时候总会发生一些变化。在之前曾抛出一个问题:为什么维度建模后的关系不是***ID,而是***Key了。这样做的目的其实就是为了解决一种被称为缓慢维度变化(slowly changing dimension)的问题。在维度变化后,一部分历史信息就被丢掉了。比如张三是某公司会员。

            但仅仅这么做还是不够的,代理码需要配合时间戳,以及行标识符使用才能解决缓慢维度变化的问题。如下CUSTOMER表使用该方法避免缓慢维度变化:

            可以看到用户张三对应新维度的TaxBracket状态由Low变成了High。如果需要统计张三的相关行为,那么可以让所有记录用CustomerID字段Join事实表;如果要统计当前TaxBracket为Low的用户状态,则可将Row Indicator字段为Current的记录用CustomerKey字段Join事实表;如果要统计历史TaxBracket状态为Low的用户情况,则只需要将TaxBracket属性为Low的用户记录的CustomerKey属性与事实表关联。

     

    数据仓库建模体系之规范化数据仓库

            所谓"数据仓库建模体系",指的是数据仓库从无到有的一整套建模方法。最常见的三种数据仓库建模体系分别为:规范化数据仓库,维度建模数据仓库,独立数据集市。很多书将它们称为"数据仓库建模方法",但笔者认为数据仓库建模体系更能准确表达意思,请允许我自作主张一次吧:)。下面首先来介绍规范化数据仓库。

            规范化数据仓库(normalized data warehouse)顾名思义,其中是规范化设计的分析型数据库,然后基于这个数据库为各部门建立数据集市。总体架构如下图所示:

            该建模体系首先对ETL得到的数据进行ER建模,关系建模,得到一个规范化的数据库模式。然后用这个中心数据库为公司各部门建立基于维度建模的数据集市。各部门开发人员大都从这些数据集市提数,通常来说不允许直接访问中心数据库。    

     

    数据仓库建模体系之维度建模数据仓库

            非维度建模数据仓库(dimensionally modeled data warehouse)是一种使用交错维度进行建模的数据仓库,其总体架构如下图所示:

            该建模体系首先设计一组常用的度集合(conformed dimension),然后创建一个大星座模型表示所有分析型数据。如果这种一致维度不满足某些数据分析要求,自然也可在数据仓库之上继续构建新的数据集市。

     

    数据仓库建模体系之独立数据集市

            独立数据集市的建模体系是让公司的各个组织自己创建并完成ETL,自己维护自己的数据集市。其总体架构如下图所示:

            从技术上来讲这是一种很不值得推崇的方式,因为将使信息分散,影响了企业全局范围内数据分析的效率。此外,各组织之间的ETL架构相互独立无法复用,也浪费了企业的开发资源。然而出于某些公司制度及预算方面的考虑,有时也会使用到这种建模体系。

     

    三种数据仓库建模体系对比

            规范化数据仓库和维度建模数据仓库分别是Bill Inmon和Ralph Kimball提出的方法。关于哪种方法更好,哪种方法更优秀的争论已经由来已久。但随着这两种数据仓库应用越来越多,人们也逐渐了解到两种数据仓库的优劣之处,如下表所示:

            产生这些区别的根本之处在于规范化数据仓库需要对企业全局进行规范化建模,这将导致较大的工作量。但这一步必须完成好,才能继续往上建设数据集市。因此也就导致规范化数据仓库需要一定时间才能投入使用,敏捷性相对后者来说略差。但是规范化数据仓库一旦建立好了,则以后数据就更易于管理。而且由于开发人员不能直接使用其中心数据库,更加确保了数据质量。还有由于中心数据库是采用规范化设计的,冗余情况也会更少。

            然而另一方面维度建模数据仓库除了敏捷性更强,而且适用于业务变化比较频繁的情况,对开发人员的要求也没有规范化数据仓库那么高。总之各有利弊,具体实施时需要仔细的权衡。

     

    小结

            数据仓库建模是一个综合性技术,需要使用到ER建模、关系建模、维度建模等技术。而且当企业业务复杂的时候,这部分工作更是需要专门团队与业务方共同合作来完成。因此一个优秀的数据仓库建模团队既要有坚实的数据仓库建模技术,还要有对现实业务清晰、透彻的理解。

    展开全文
  • 数据仓库维度建模

    2020-01-08 15:47:15
    数据仓库维度建模 数据仓库作用:将不同数据资源整合,为企业决策提供数据支撑。 维度建模:顾名思义就是以不同维度的角度分析数据而建立的数据模型。 模型层级概览: 红色框框内为数据仓库基础层级划分 stg(缓冲层...

    数据仓库维度建模

    数据仓库作用:将不同数据资源整合,为企业决策提供数据支撑。
    维度建模:顾名思义就是以不同维度的角度分析数据而建立的数据模型。

    模型层级概览:

    数据仓库模型简图

    ODS(贴源层):将接入的不同类型的源数据清洗、转换等操作,保持数据与源系统一致
    DIM(维度层):从贴源层中获取数据,整合维度信息数据,用于数据的维度分析。
    DWD(数据仓库层):通过业务模型整合出来的事实明细层。
    DWS(主题层):通过业务模型以及维度分析模型整合的主题层数据。
    ADS(应用层):对外应用层,存储对外数据应用服务的数据。

    维度建模又可分为:星型模型和雪花模型。
    星型模型:一张事实表可以从多张不同维度信息表来统计分析数据,或者一张维度信息表可以分析不同的事实表。
    在这里插入图片描述
    雪花模型:雪花模型其实就是星型模型的进化版,随着业务数据的增长,业务类型的多样化,普通的星型模型难以满足数据统计分析,便会慢慢演变成雪花模型,一张事实表可以从多张不同维度信息表来统计分析数据,且一张维度信息表可以分析不同的事实表,以此维度表和事实表相互扩张,又如雪花一样相互依赖。
    在这里插入图片描述

    展开全文
  • 农作物信息数据仓库维度建模初探,周志艳,罗锡文,本文根据维度建模的一般方法,结合农作物空间信息数据的特点,给出了农作物信息数据仓库的维度模型,包括该数据仓库的总线矩阵、
  • 从其它地方找到的, 关于数据仓库维度建模, 对初学者有帮助.
  • 大数据-数据仓库维度建模

    千次阅读 2019-05-15 11:09:22
    数据仓库维度建模一、维度建模(dimensional modeling)1. 维度表(dimension)2. 事实表(fact table)二、维度建模的三种模式1. 星形模式(Star Schema)2. 雪花模式(Snowflake Schema)3. 星座模式(Fact Constellations ...

    一、维度建模(dimensional modeling)

    是专门用于分析型数据库、数据仓库、数据集市建模的方法。

    1. 维度设计的主要流程

    (1) 选择业务过程

    业务过程是组织完成的操作性活动,业务过程事件建立或获取性能度量,并转换成事实表中的事实。业务过程定义了特定的设计目标以及对粒度、维度、事实的定义。通过对业务需求以及数据源的综合考虑,决定选择哪种业务过程开展建模工作

    (2) 声明粒度

    粒度用于确定某一事实表中的行表示什么。粒度声明是设计必须履行的合同。在选择维度或事实前必须声明粒度,某个候选维度或事实必须与定义的粒度保持一致。在所有的维度设计中强制实行一致性是保证BI应用性能和易用性的关键。

    (3) 确认维度

    维度==提供围绕某一业务过程事件所涉及的“谁、什么、何处、何时、为什么、如何”==等背景。

    (4) 确认事实

    事实涉及来自业务过程事件的度量,基本上以数量值表示。
    与之前在操作型数据库中介绍的关系建模方法相比增加两个概念:

    1. 维度表(dimension)

    表示对分析主题所属类型的描述,通常来说维度表信息比较固定且数据量小。

    2. 事实表(fact table)

    表示对分析主题的度量,事实表包含了与各维度表相关联的外码,并通过JOIN方式与维度表关联。事实表的度量通常是数值型,且记录会不断增加,表规模迅速增长。

    事实属性:

    (1)对应维度的外码
    (2)度量属性
    (3)事务标识码
    如:各种 订单号、事务编号。。。将这种逻辑意义上的维度放到事实表里的做法称为退化维度,为的是加快查询。
    (4)事务时间

    二、维度建模的三种模式

    1. 星形模式(Star Schema)

    最常用的维度建模方式。由一个事实表和一组维度表组成。特点:
    (1) 维度表只和事实表关联,维度表之间没有关联;
    (2) 每个维度表的主码为单列,且该主码放置在事实表中,作为两边连接的外码;
    (3) 以事实表为核心,维度表围绕核心呈星形分布
    在这里插入图片描述

    2. 雪花模式(Snowflake Schema)

    对星形的扩展,每个维度表可继续向外连接多个子维度表。雪花模型相当于将星形模式的大维度表拆分成小维度表,满足规范化设计。实际应用少,虽减轻数据冗余问题,但导致开发难度增大。
    在这里插入图片描述

    3. 星座模式(Fact Constellations Schema)

    星形的扩展,多个维度表,一个维度表被多个事实表用到。业务发展后期,绝大数采用此模式。

    作用:

    (1)共享维度
    (2)细节/聚集事实表
    细节事实表:每条记录表示单一事实;通常设有事务标识码(TID)属性
    聚集事实表:每条记录聚集了多条事实;无TID

    4. 模式对比

    在这里插入图片描述

    【参考博客】

    三、缓慢变化维度问题

    虽然维表数据一般比较稳定,当有时维表会发生一些变化。比如,张三所在部门(张三刚开始在研发部,之后调到信息中心部,那么值钱张三在研发部的历史信息就被丢掉)
    解决办法
    (1)关系用***Key,而不是ID(不同key可对应同一个员工id)
    (2)行标识符、时间戳

    在这里插入图片描述
    参考博文

    四、数仓建模体系

    1. 规范化数仓

    在这里插入图片描述

    2. 维度建模数仓

    在这里插入图片描述

    3. 独立数据集市

    在这里插入图片描述

    4. 三种数仓建模体系对比

    在这里插入图片描述在这里插入图片描述
    参考博文

    展开全文
  • 数据仓库 维度建模 维度表Generally, only 5V's of big data are discussed. But here we will also talk about the sixth one and will also understand why we should not ignore the 6th one. 通常,仅讨论5V的...

    数据仓库 维度建模 维度表

    Generally, only 5V's of big data are discussed. But here we will also talk about the sixth one and will also understand why we should not ignore the 6th one.

    通常,仅讨论5V的大数据。 但是在这里我们还将讨论第六个,也将理解为什么我们不应该忽略第六

    The most commonly discussed 5 Big V's of Big Data are:

    讨论最多的5个大数据大V是:

    1. Volume

    2. Variety

      品种

    3. Velocity

      速度

    4. Veracity

      真实性

    5. Valence

    And the sixth v that we will discuss here is Value.

    我们将在这里讨论的第六个v是Value

    Now let's discuss about all the v's in brief,

    现在让我们简短地讨论所有v

    1)音量 (1) Volume)

    In the name itself of Big data the word big is mentioned, means the data big, it's voluminous.

    在大数据本身的名称中,提到了“大”一词,意思是大数据,它是庞大的。

    Over millions of petabytes of data are produced per minute. We cannot even imagine of all the time, cost, energy that will be used to store and extract sense out of such an amount of data.

    每分钟产生数百万PB的数据。 我们甚至无法想象所有时间,成本和精力都将用于存储和提取如此大量数据中的感觉。

    Also, there is the number of challenges we should encounter while dealing with the massive volume of big data. Specifically, the storing of data, the amount of storage space required to store that data efficiently will also be large. However, we also need to be able to retrieve that large amount of data fast enough and move them to processing units in a timely fashion to get results when we need them. This brings additional challenge such as networking, bandwidth, and cost of storing data.

    此外,在处理海量大数据时,我们还应该面对许多挑战。 具体地,数据的存储,有效地存储该数据所需的存储空间量也将很大。 但是,我们还需要能够足够快地检索到大量数据,并及时将它们移至处理单元以在需要时获得结果。 这带来了额外的挑战,例如网络,带宽和存储数据的成本。

    2)品种 (2) Variety)

    Variety is a form of scalability. Here scale does not refer to the size it refers to increased diversity.

    多样性是可扩展性的一种形式。 这里的规模不是指规模,而是指增加的多样性。

    Just think over the internet, or in our daily lives also we came across different types of data. Text files, embedded images, videos etc.

    只是想想互联网,或者在我们的日常生活中,我们也遇到了不同类型的数据。 文本文件,嵌入式图像,视频等

    So, variety is also another important thing we need to deal with cause data that produce is very varied in manner.

    因此,多样性也是我们需要处理的另一件事,原因是产生的数据的方式差异很大。

    3)速度 (3) Velocity)

    By velocity we refer to the high speed at which the data is created and according to which data needs to be stored and analyzed. We should match our processing speed with the speed at which the data is produced because if a business cannot take advantage of the data as it gets generated, because of timing problem, they often miss opportunities. Velocity is an important factor of data, being able to catch up with the velocity of big data and analyzing it as it gets generated can even impact the quality of human life. For example, sensors and smart devices monitoring the human body can detect abnormalities in real time and trigger immediate action, potentially saving lives.

    通过速度,我们指的是创建数据以及根据其需要存储和分析数据的高速。 我们应该将处理速度与数据的生成速度相匹配,因为如果业务由于时序问题而无法利用生成的数据,则它们往往会错失机会。 速度是数据的重要因素,能够赶上大数据的速度并在生成数据时对其进行分析甚至会影响人类的生活质量。 例如,监视人体的传感器和智能设备可以实时检测异常并立即采取措施,从而有可能挽救生命。

    4)真实性 (4) Veracity)

    By veracity, we refer to the quality of the data. Big data is varied, generated at a high speed so, it is likely to be noisy and uncertain. It can be full of biases, abnormalities and it can imprecise. "There is no value of data if it is not accurate".

    通过准确性,我们指的是数据的质量。 大数据是多种多样的,并且是高速生成的,因此,它可能是嘈杂的和不确定的。 它可能充满偏差,异常并且可能不精确。 “如果数据不正确,将没有任何价值”

    5)价 (5) Valence)

    Valence refers to the connectedness. The more connected data is the higher its valences. The term comes from chemistry, remember we talk about valence electrons in chemistry. Valence electrons are in outermost shells, have the highest energy level and are responsible for bonding with other atoms. Higher valence results in greater bonding, that is greater connectedness.

    价是指联系。 连接的数据越多,其价数就越高。 该术语来自化学,记住我们谈论化学中的价电子。 价电子位于最外层的壳中,具有最高的能级,并与其他原子键合。 价数越高,键合越好,即连通性越强。

    For a collection of data valence measures the ratio of actually connected data items to the possible number of connections that could occur within the collection.

    对于数据集合,量度度量实际连接的数据项与该集合内可能发生的连接的可能数量之比。

    The most important aspect of valence is that the data connectivity increases over time.

    价的最重要方面是数据连接性随时间增加。

    Above we discussed the 5 v's of big data often referred to as the dimensions of big data. Each of them shows us the challenges associated with different dimensions of big data namely, size, complexity, speed, quality, and connectedness.

    上面我们讨论了大数据5个v,通常称为大数据的维度 。 他们每个人都向我们展示了与大数据的不同维度(大小,复杂性,速度,质量和连接性)相关的挑战。

    At the heart of the big data, the challenge is turning all of the other dimensions into truly useful business "value".

    在大数据的核心,挑战在于将所有其他方面变成真正有用的业务“价值”

    So, this value is our sixth v. The main purpose between collecting, storing, analyzing and all the other things we do is to extract "Value" from Big Data.

    因此,该值是我们的第六个v 。 收集,存储,分析以及我们所做的所有其他事情之间的主要目的是从大数据中提取“价值”

    Dimensions of Big Data

    Conclusion:

    结论:

    In the above article, we discussed all the dimensions of big data and also got introduced to the 6th v of big data i.e. value, which is the heart of all the other processes. For any further queries shoot your questions in the comment section below. Will see you in my next article till then stay healthy and keep learning!

    在上面的文章中,我们讨论了大数据的所有维度,还介绍了大数据的第六个维度,即value ,这是所有其他过程的核心。 如有其他疑问,请在下面的评论部分中提出您的问题。 在我的下一篇文章中将看到您,直到您保持健康并继续学习为止!

    翻译自: https://www.includehelp.com/big-data/dimensions-of-big-data.aspx

    数据仓库 维度建模 维度表

    展开全文
  • 数据仓库维度建模介绍,数据仓库设计的朋友们可以参考!
  • 一本关于数据仓库维度建模的完全指南,详细介绍了怎么样数据仓库维度建立。
  • 文章目录1. 维度建模基本概念1.1. 维度表(dimension)1.2. 事实表(fact table)2. 维度建模三种模式2.1...维度建模(dimensional modeling)是专门用于分析型数据库、数据仓库、数据集市建模的方法。数据集市可以理解...
  • 数据仓库维度建模设计原则及应用,不错的文档,可供大家下载,一起学习。
  • 数据仓库工具箱 维度建模权威指南(第3版) 数据仓库建模经典之作,构建数据仓库必看!

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,134
精华内容 453
关键字:

数据仓库维度建模