精华内容
下载资源
问答
  • 小维度和大维度 数据仓库中许多记录都是在小中,中记录很少,字段只有一两个。创建这些时应当保留最初的源,经常会有新的记录添加。小维度可能出现在很多数据集市中,

    小维度和大维度

    数据仓库中许多记录都是在小表中,表中记录很少,字段只有一两个。创建这些表时应当保留最初的源表,经常会有新的记录添加。小维度可能出现在很多数据集市中,因此经常把多个小维度合并成一个大的维表,从而简化设计。冗余维的ETL流如下图所示:

    由于增量建立的冗余维在合并代码时可能比笛卡尔积小的多,因此冗余维的记录可以在整合数据时创建。

    在维表模型中,经常假设各个维表之间是相互独立的。但是按严格的数据角度,经常合并维度,即使两个维度不属于同一个层系,但是从结果来看,两个维度的相关性足够强并且合并后的结果足够小,这两个维度也应该合并在一起。如果不满足上述条件,则两个维度就是相互独立的。

    角色维度

    在数据仓库中,相同的事实表被多次指定一个维度时,称为角色维度。最常见的维度是日期维度。在所有角色维度中,书中推荐建立一个统一的维表,然后基于此统一的维表建立不同的角色视图。若使用大维度表则应该在不同的子集中创建物理表,避免使用视图破坏性能。

    退化维

    在维表中出现父子关系,父维度的自然键是子维度的主键,并且子维度的主键可以创建一个单一列的维度,则称为退化维或者空维。

    缓慢变化维

    当数据仓库被告知一条已经存在的维度记录在某些方面发生了变化,会生成3种基本响应,这三种基本响应被称为装在1、2、3的缓慢变化维。

    类型一缓慢变化维为覆盖,是对已经存在的维度记录的一个或多个属性进行复写。当数据被矫正而不需要保留历史记录或不需要执行以前的报表可以选择1SCD:

    为了提高ETL的性能,应该将更新现有数据的过程和插入新数据的过程区分开,并分别向数据仓库回馈。在大多数数据仓库执行的过程中,大多数维度的大小是可以忽略的。如果装载小表不需要调用大量加载,类型一的变化可以通过标准的DML实现。

    在ETL中第一类缓慢变化维有可能引起性能问题。如果通过SQL数据操作语言实现这种技术,大部分数据库管理系统会在日志中记录事件发生,损耗系统性能。数据库日志由数据库管理系统在后台创建和维护。对于数据进入转换处理用户无控制的情况下,数据库日志显得尤为重要。在线交易处理情况下,无法对用户的行为进行控制,而数据库日志可以记录回滚、撤销或更新失败的操作。相反的,数据仓库中,所有的数据装载都由ETL处理控制。如果处理失败,那么ETL应该有能力从错误中恢复和标记中断。激活数据库日志会使大维度表装在效率下降。一些数据库管理系统可以允许在某些数据操作语言处理开始的时候关闭日志,而且当触发批量导入器的时候也要关闭数据库日志。如果是大量的第一种类型维度转换,减小数据库管理系统负担的一个最好的方法是使用批量装载器。在单独表中准备新的维度记录。从维度表中删除记录并重新批量加载。

    类型二的缓慢变化维是在维度实体中追踪变化,并正确关联到事实表的标准基本技术。基本原理是:当数据仓库被告知一条现有的维度记录要更改而不是重写的时候,数据仓库会在变化时发布一条新的维度。新的维度记录还会分配一个新的代理主键。在此之前,所有的有维度的事实表中,代理主键被用作外键。只要在发生改变的时刻,代理键分配的得当,那么不会有任何一个已有的事实表中的键值需要改变或跟新,已有的聚合事实表也不需要重新计算。

    由于维度实体的每个细节版本都正确连接到事实表记录,因此第二种缓慢变化维度完美的区分了历史表。书中给的例子如下图:

     

    上图是一名叫Jane Doe的员工维度记录。他最开始是实习生,然后转为正式员工,最后成为管理人员。Jane Doe的自然键是他的员工编码,这是他工作期间一直保持不变的编码。

    如果一个维度的自然键可以变化,从数据仓库的观点上,它不是真正含义上的自然键。因此,数据仓库要求使用更加符合基本原理的代理键。

    第二种缓慢变化维度需要在ETL环境中有一个良好的变化数据捕获系统,一旦元数据发生变化就要探测到,这样数据仓库就会生成新的维度记录。对维表代理键的管理如下图:

     

    一般ETL系统会为维度的每一个列保留一个策略,这个策略决定了当变化发生时,应触发哪种变化类型。书中推荐在维度表中增加以下5个字段来处理类型2的逻辑:

    • 日历日期外键(变化日期)
    • 行有效时间日期(变化的精确时间日期)
    • 行结束时间日期(下一个变化的时间日期)
    • 变化理由(正文字段)
    • 当前标志(当前/期满)

    这五个字段可以让维度支持强大的查询甚至在查询里不需要事实表。当维度实体发生替代变化的时候,要把标志设为终止(expired)

    当维度记录发生变化,但属性原来的值仍保持有效性的时候,要使用第三种缓慢变化维度。在第三种缓慢变化维度中,当变化发生的时候,生成新的一列而不是新的一行。在新的主值复写之前,原来的值就被放置在这一列中。

    在常规的数据流传递途径上,第三种方式不经常出现,这种方式的管理以手工的方式开始,如果变更的属性没有交替字段的话,甚至可以包括结构计划的更改。

    响应属于第三种SCD类型的维度属性变化的结果是基于字段到字段的。在一个维度中通常可以包括第一种类型和第二种。当第一种类型字段发生变化,字段中的值被复写。第二种类型变化,就生成一个新记录。也有可能在一条维度记录中混合三种不同的变化类型:

     

    滞后到达的数据在数据仓库中呈现出一种复杂的状态,需要通过不同的方法抽取或与常规数据不同的结束,劣质数据在数据清洗阶段就要筛选出来。

    更新事实表记录要在测试环境中心小心处理,然后才可以实施到生产系统中。若数据库系统对更新操作有保护措施的话,要注意更新不会设计到海量数据。从操作的目的上看,大量的更新会被分为不同的块,没有必要把时间浪费在百万记录更新失败的回滚上。

    为了避免桥接表和事实表的多对多连接,必须创建一组实体关联到海量值维度。在许多情况下,都是需要桥接表,但是没有合理分配加权系数的基准。如果海量值维度是第二种缓慢变化维度,桥接表必须是随时间变化的。

    不规则层次的不可测深度在数据仓库中是重点。书中介绍了两种维度方法,递归指针方法和层次桥接表方法,分别如下图:

     

     

    对于关系型数据库用SQL语句存储一些严格约束的分析类型的接口,需要展现在维度记录上的复杂对比。以上为提交维表的相关内容,由于对内容的理解比较生僻,所以好多地方只能抄书,估计再多学习以下这方面的只是应该就可以理解了。下篇我们将介绍提交事实表的相关内容。

     

     

    展开全文
  • 一、概述 星型模型设计,经常...那么问题来了,模型设计时,在逻辑模型层次如何表征这种关系,在物理模型层,又如何实现这种关系。人是活的,技术是死的,条条大道通罗马,没有火车飞机,马可波罗一样来到到了中国。

    一、概述

          星型模型设计,经常遇到的问题便是,此业务过程之维度,恰恰是另外一个业务过程的事实。最简单的例子如,产品销售业务活动,以订单为事实,以客户、产品、销售人员等为维度;而产品维度,在产品生产业务过程中则作为事实存在。那么问题来了,模型设计时,在逻辑模型层次如何表征这种关系,在物理模型层,又如何实现这种关系。人是活的,技术是死的,条条大道通罗马,没有火车飞机,马可波罗一样来到到了中国。总有解决的办法,但是每种方式都有优劣,在此对比一下吧。

    二、可选方案

         方案一:构建单独的产品维表,产品维表+产品事实表模式;

               优势:

               劣势:

         方案二: 构建虚拟的产品维表,虚拟产品维表(只含标识)+产品事实表模式;

               优势:

               劣势:

     

          方案三:产品事实表,直接使用产品事实表;

     

               优势:

               劣势:

           方案四:构建产品视图作为产品维表使用,产品视图+产品事实表;

               优势:

               劣势:

    三、推荐方案:

           你推荐那种方案呢,欢迎留言。

     

    展开全文
  • 本文发表于中文核心刊物《计算机工程与设计》2005年1期。 基于关系数据库的数据仓库星形模式使用原则的研究与探索 ...

             本文发表于中文核心刊物《计算机工程与设计》2005年1期。

     

     

    基于关系数据库的数据仓库星形模式下维使用原则的研究与探索

                                                                                                          马根峰  

                                                                                         (广东电信公用电话管理中心  广州 510635)

    摘要    星形模式是基于关系数据库的数据仓库中的一个著名概念,由于星形连接模式的设计思想能够满足人们从不同观察角度(维)分析数据的需求,所以在基于关系数据库的数据仓库的设计中广泛地使用了星形模式。在使用数据仓库来回答综合性问题的场合,通常可以使用OLAP工具实现记录不多的较高粒度表的维度旋转来满足不同分析的需要;而在数据仓库中较高粒度表中记录非常多或者还要经常回答细节问题的场合,则还必须对数据仓库中记录非常多的较高粒度的表或者细节级表进行维度转换。但通常的OLAP工具难以处理几十万条记录数据表的维度旋转,针对这种应用场合,笔者提出了一种”有选择地使用维的星形模式”,在事实表中避开使用要旋转的维,用存贮过程编写程序高效地实现OLAP工具相应的功能,对星形模式下维的使用原则做出了一定的探索。

    关键词    数据仓库;星形模式;维度 ;OLAP

     

     

    the research of the restricted use of Dimensionality in Star Schema in Data Warehousing based on RDS

                                                                  MA Gen-feng     

             (Public Payphone Center, Guangdong Telecom Corporation, Guangzhou 510635)

    ABSTRACT:  Star Schema is a famous conception in Data Warehousing based on RDS. It’s widely used in Data Warehousing based on RDS for its convenience for people to analyze data from different angle. In the situation for people using Data Warehousing to answer the all-around question, OLAP tools is usually used to circumrotate the Dimensionality of high granularity tables with a few records for the requirement of analyse. If there is a great deal records in high granularity tables or In the situation for people using Data Warehousing to answer the detail question, it’s necessary to circumrotate the Dimensionality of those high granularity tables or the detail tables in Data Warehousing. While it’s very difficult for OLAP tools to circumrotate the dimensionality of tables with more than ten thousands records, I issue a new Star Schema with restricted using of dimensionality. In this Star Schema the fact tables without the dimensionality to be circumrotated is designed, then I develop a program using stored procedure to implement the corresponding function of OLAP tools in high efficiency. In this process definite research is done about the rule of using dimensionality in Star Schema in RDS.

    KEY WORDS: Data Warehousing; Star Schema; Dimensionality; OLAP

     

     

     

    1 引言

     

             星形模式是基于关系数据库的数据仓库中的一个著名概念,由于星形连接模式的设计思想能够满足人们从不同观察角度(维)分析数据的需求,加上数据仓库通常用来回答综合性的问题,并且通常的OLAP工具可以很轻松地实现记录不多的较高粒度表的维度旋转来满足不同分析的需要,所以在基于关系数据库的数据仓库的设计中广泛地使用了星形模式,如电信运营商中普遍进行的话务总体分析。在这种总体分析中,主要分析某一计费月各地区的总体话费及其在不同计费月期间的变化。

     

             而在数据仓库中较高粒度表中记录非常多或者还要经常回答细节问题的场合,则还必须对数据仓库中记录非常多的较高粒度的表或者细节级表进行维度转换。如在目前电信市场尤其是公话市场竞争激烈的今天,广东电信公用电话管理中心的经营分析人员迫切进行的公话终端(首先是一百多万部200专用话机)话费的动态分析。在这种话费的动态分析中,不仅要分析分析各地区、各市县、各支局、各用户类型以及它们不同组合情况下的200专用话机在某一计费月的总体话费及其在不同计费月的变化,而且还要从细节上分析带来这些变化的一百万多万部200专用话机在某一计费月的话费在不同计费月期间的变化。因为只有这样才能了解200专用话机总体话费及其变化的原因或找出其中的规律,为管理者决策提供依据。但通常的OLAP工具难以处理几十万条记录数据表的维度旋转,更不用说是对每个月都有一百多万条话费记录的200专用话机话费细节表在时间维度上的旋转了。笔者在”基于数据仓库和维度转换的广东电信公用电话200专用话机话务的动态分析系统”的研究与开发过程中,在数据仓库星形模式设计时有选择地使用维,在星形模式中各粒度200专用话机话费表中避开使用时间维,然后用存贮过程编写维度转换程序代替OLAP工具来旋转操作型环境下话费表中的时间维,在PC机上每一次只需要一个小时就完成了一个月一百多万条记录的操作型环境下话费表的维度转换并生成了数据仓库中各粒度表的数据,轻松地实现了一百多万部200专用话机话费的动态分析,对数据仓库星形模式下维的使用原则做出了一定的探索。

     

     

     

    2  只回答综合性问题场合下的星形模式及OLAP处理

     

      2.1 星形模式设计

             在只回答综合性问题的场合,也是绝大多数应用数据仓库的场合,由于OLAP只涉及数据仓库中记录不多的较高粒度的表,所以在这种场合,数据仓库中各粒度表都使用尽可能多维的星形模式。如下面电信运营商为了进行总体话费分析所采取的星形模式,在这种星形模式下,事实表中包含着用于分析的指标(话费)和联接众多维表的主键。

     

                        

      

     

     ......

     

         



        

     

    2.2  使用OLAP工具进行话费总体分析

             对于图2中的高度综合表,由于广东电信下属22个分公司,公用电话话机有20种类型,所以10年内表中的记录数为52800条记录,所以完全可以用OLAP工具对高度综合表进行维度转换,将时间维从事实表中去掉来完成几个月来各地区、各话机类型或者各地区的各种类型话机话费的总体变化,完成总体话费的分析。

     

     

     

    3 有选择地使用维的星形模式及话费动态分析的实现

     

             在图1至图3中,如果要进行各地区、各市县、各支局不同类型话机话费的动态分析,则还必须对图2中的轻度综合级表进行维度转换,而广东电信现有1400多个支局,那么一年内轻度综合级表中的记录就达到30多万条,在这种情况下用OLAP工具来分析几年间话费的变化就难以实现,更不用说对一年内就达1200多万条记录的200专用话机话费细节表进行200专用话机进行话费的动态分析了。笔者曾经使用OLAP工具BrioQuery在PC机上实现200万条记录的话费细节表在时间维度上的转换,运行135个小时也没有转换成功。在电信市场尤其是公话市场竞争日益激烈的今天,为了实现经营分析人员所迫切进行的200专用话机话费的动态分析,必须对上面的星形模式进行特殊的处理,笔者所采用的方法是在事实表中有选择地使用维,将事实表200专用话机话务中的时间维去掉,在事实表中增加各个时间维成员作为事实表的字段,使用存贮过程编写维度转换程序来代替OLAP的操作。

     

        3.1有选择地使用维的星形模式

         
                               


     …     


       


     

             对于关系模式的这种设计,大家可能会一方面质疑它的扩展性,即它能进行其它时期话费的动态分析吗?另一方面可能会质疑如果它可以扩展来进行其它时期话机话费的动态分析,那最多进行多少年话机话费的动态分析?在笔者开发的200专用话机话费的动态分析系统中,只要在选择性使用维的星形模式中各级话费表中增加几个月份的金额字段,在我编写的维度转换程序中增加几个变量及几条赋值语句,就可以统计分析许多年的话费数据;两者,MS SQL SERVER7.0最多支持1024列的表,这可以用来统计分析80多年的数据。

     

    3.2 话务表中时间维的旋转

             在笔者开发的200专用话机话费的动态分析系统中,笔者采用的方法是每个月对该月的话机话务表和图4中的细节表进行合并,这样做的优点一是每次只需要处理一个月一百多万条200专用话机话费记录,而不是像OLAP工具那样处理n个月的话费数据;二是经过查询优化,在PC机上每一个月200专用话机话费表的合并操作只需要一个小时的处理时间。具体合并过程如下图所示:

     
                                   

     

     

    4 结束语

     

             对于使用数据仓库来回答综合性问题的场合,星形连接模式可以满足决策者从不同的维来观察数据的需求,并且通常的OLAP工具可以实现记录不多的综合级表的维度旋转。笔者曾在PC机上使用某一OLAP工具来实现两个月200多万条话费记录的维度转换时,运行了xx小时也没有完成时间维的转换操作。而在数据仓库中较高粒度表中记录非常多或者还要经常回答细节问题的场合,则还必须对数据仓库中记录非常多的较高粒度的表或者细节级表进行维度转换。如分析电信运营商中几十万、几百万乃至于几千万部话机在时间维不同维成员的话费变化时,通常的OLAP工具却难以完成这样的操作。笔者在”广东电信公用电话200专用话机话务的动态分析系统”的研究与开发过程中,在数据仓库设计时有选择地使用维,在星形模式中各粒度200专用话机话费表中避开使用时间维,然后用存贮过程编写维度转换程序代替OLAP工具来旋转操作型环境下话费表中的时间维,在PC机上每一次只需要一个小时就完成了一个月一百多万条记录的话费表的维度转换并生成了数据仓库中各粒度表的数据,轻松地实现了一百多万部200专用话机话费的动态分析,对数据仓库星形模式下维的使用原则做出了一定的探索。

     

     

    参考文献:

    [1]  王珊 · 数据仓库技术与联机分析处理 · 北京:科学出版社,1998.6

    [2]  Michael Corey(美),Michael Abbey(美) · SQL SERVER 7 Data Warehousing · 北京:希望电子出版社,2000.1

    [3]  袁鹏飞 · SQL Server 7.0数据库系统管理与应用开发 · 北京:人民邮电出版社,1999.5

     

    转载于:https://my.oschina.net/qzhlove/blog/333382

    展开全文
  • 地理位置维表的设计模型是什么?3. geohash地理位置字典构建的流程你能描述一下吗?4. geohah编码的算法思想能够描述一下? 1. 为什么要构建一个地理位置维表(字典) 2. 地理位置维表的设计模型是什么? 3. geo...

    1. 为什么要构建一个地理位置维表(字典)

    2. 地理位置维表的设计模型是什么?

    3. geohash地理位置字典构建的流程你能描述一下吗?

    4. geohah编码的算法思想能够描述一下?

    展开全文
  • 前面说到过,维模型的典型结构就是维表+事实表。一个事实表+关联的多个维表,组成一个星型模型。多个事实表+多个可能共享的维表组成星系模型
  • ETL工具箱 5提交维表

    2012-10-06 00:46:00
    维度的基础框架 ...(大多数关系型数据库维表和事实表通过单一字段连接获得最大性能,当外键是数字类型的时候事实表是最为紧凑的) 维表将其他的一个或者多个字段组成维表的自然键(natural ke...
  • 文章目录1 数仓分层1.1 基本分层模型1.2 数据集市和数据仓库2 数仓理论2.1 范式理论2.2 关系建模和维度建模2.2.1 关系建模2.2.2 维度建模2.2.2.1 维度建模的三种模型2.3 维度和事实2.3.1 维度2.3.2 事实 ...
  • 一、事实 特点: 1. 由一组表示维度的键和一组数字形式的度量值构成。 2. 维度外键通常是一些数字或字符代码,因为通常事实会包含极大的数据量,如果直接使用维度描述的话,会对存储性能照成影响。 3. 每个...
  • 一个宽表好还是多个维表好?

    千次阅读 2019-12-24 11:38:10
    Dimension Table概念多出现于数据仓库里面,维表与事实表想对应,比如一个 “销售统计表” 就是一个 事实表,而 “销售统计表” 里面统计数据的来源离不开 “商品价格表”,“商品价格表” 就是销售统计的一个维度表...
  • 专业数据仓库面临的一个问题是数据仓库中数据库设计的基本模型选取问题。广泛采用的数据库设计模型有两种,关系型和多维型。 下面介绍两种模型,及其两种方法的区别和在数据仓库中的应用,两种方法的优缺点。在建立...
  • oracle用户与空间关系 用户=商家 =商品 空间=仓库 1个商家能有很多商品,1个商品只能属于一个商家 1个商品可以放到仓库A,也可以放到仓库B,但不能同时放入A和B 仓库不属于任何商家 商家都有一个默认的仓库,...
  • 其可以使用一张二维表进行关系呈现。 关系模型由数据结构、数据操作和完整性约束三部分构成。其中数据结构是指数据自身的组织形式;数据操作是指对数据进行的增删改查的操作,而对数据的查询是该模型中最为重要的...
  • 数据仓库@缓慢变化(拉链算法)

    千次阅读 2019-10-08 21:09:14
    前言 维度中的数据来源于操作型系统。在多维数据仓库或独立型数据集市中,数据直接来源于操作型系统。在企业信息化工厂中,...由于下游的星型模式使用代理键作为每个维度的主键,因此不需要像原系统那样处理信...
  • 关系模型和SQL

    2019-06-27 21:01:42
    文章目录一、数据库的发展:关系模型和SQL安装三、SQL语句:1.DCL控制语言2.DDL数据定义语言3.DML数据操作语言4.TCL事务控制语言 一、数据库的发展: 萌芽期:文件管理 第一代:层次数据库、网络数据库 第代:...
  • 关系模型的相关术语

    千次阅读 2019-03-22 22:38:55
    关系:整个二维表 关系名:表格名称 元组:行数据(记录) 属性:列数据(字段/分量) 属性名:列名称(字段名) 主键:唯一确定元组的属性组(关键字) 域:属性的取值范围 关系模式关系的描述,表示为:关系名...
  • 引子 流计算中一个常见的需求就是为数据流补齐字段。因为数据采集端采集到的数据往往比较有限,在做数据分析之前,就要先将所需的维度信息...这里所说的维表与数据仓库中的概念类似,是维度属性的集合,比如商品维...
  • * 数据仓库构建难点: 1.主题的准确划分,需要经常进行的整合,有些因为别人使用而无法废弃,的数量越来越多 ...4.多层次的模型,导致每增加一个指标都需要在多个层次的中同步维护,人力成...
  • 定义:用二维表格来表示实体集,用关键码表示实体之间联系的数据模型称为关系模型 有时也习惯称呼关系或表格,元组为行(Row),属性为列。关系中属性个数称为“元数”,元组个数称为“基数” 关键码(Key,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 13,741
精华内容 5,496
关键字:

仓库的关系模型的二维表