ITPub博客

--[@more@]在维度建模的数据仓库中，有一种维度表叫multivalue dimension，中文一般翻译为“多值维度”。多值维度有两种情况，第一种情况是指维度表中的某个属性字段同时有多个值。举例来说，一个帐户维度表中，帐户持有人姓名，可能会有多个顾客。这样，一个帐户对应多个顾客姓名，一个顾客也可以有多个帐户，它们之间是多对多的关系。正因为一个帐户可能会有多个对应的顾客，所以不能直接将顾客ID放入帐户维度表中。而帐户维度表中的这种情况就叫做多值维度。多值维度的第二种情况是事实表在某个维度表中有多条对应记录。举例来说，对于

--[@more@]《数据仓库工具箱—维度建模的完全指南》是数据仓库建模方面的经典著作， 1996年第一版出版被认为是数据仓库方面具有里程碑意义的事件。作者kimballl是数据仓库方面的权威，他将多年的数据仓库建模实战经验、技巧融入本书。他提出的许多维度建模概念被广泛应用于数据仓库的设计和开发中。2002年本书出版了第二版。这是一部非常好的数据仓库建模的书，前后完整的读了三遍，受益匪浅。以下笔记将本按四个部分组织：一、数据仓库体系结构和建模过程、技巧。二、维度表建模技术。三、事实表建模技术。四、行业建模经验。一、数据仓库

--[@more@]来源：中国商业智能网 维度建模中一个非常重要的步骤是定义事实表的粒度。定义了事实表的粒度，则事实表能表达数据的详细程度就确定了。定义粒度的例子如下：1．客户的零售单据上的每个条目。2．保险单上的每个交易。定义好事实表的粒度有很大的用处。第一个用处就是用来确定维度是否与该事实表相关。例如，对于粒度细到医疗单据上条目项的事实表来说，医疗结果是不会作为维度和它进行关联的，因为它们不在同一个粒度上。但是，对于一般的E/R数据模型来说，医疗单据是和医疗结果是进行关联的。通常的规范化建模里没有粒度的概念

--[@more@]1：确定数据范围 确定数据范围实际上是对ODS进行主题划分的过程，这种划分是基于对业务系统的基础上而进行的，并不十分关心整个数据仓库系统上端应用需求，但是需要把上端应用需求与ODS数据范围进行验证，以确保应用所需的数据都已经从业务系统中抽取出来，并且得到了很好的组织。一般来讲，主题的划分是以业务系统的信息模型为依据的，设计者需要综合各种业务系统的信息模型，并进行宏观的归并，得到企业范围内的高层数据视图，并加以抽象，划定几个逻辑的数据主题范围。在这个阶段，以ER模型表示数据主题关系最为恰当。2：

---[@more@]作项目分析，数据库设计是一个很重要也很难的问题，完全按照范式有可能不符合用户需求，不利于编程，看来是具体问题具体分析，数据库设计是范式和需求的折中。在上学时，没觉得数据类型有多重要，现在发觉了解数据类型的具体内容也是很重要的，可以知道不同数据库之间的兼容问题该怎么处理。数据库设计技巧：第2 部分— 设计表和字段1. 检查各种变化我在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。比方说，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，我倾向

-[@more@]ETL学习心得：探求数据仓库关键环节ETL的本质 做数据仓库系统，ETL是关键的一环。说大了，ETL是数据整合解决方案，说小了，就是倒数据的工具。回忆一下工作这么些年来，处理数据迁移、转换的工作倒还真的不少。但是那些工作基本上是一次性工作或者很小数据量，使用access、DTS或是自己编个小程序搞定。可是在数据仓库系统中，ETL上升到了一定的理论高度，和原来小打小闹的工具使用不同了。究竟什么不同，从名字上就可以看到，人家已经将倒数据的过程分成3个步骤，E、T、L分别代表抽取、转换和装载。其实ETL过程就是数据流动的过程

－[@more@]简介数据集成是数据仓库中的关键概念。ETL（数据的提取、转换和加载）过程的设计和实现是数据仓库解决方案中极其重要的一部分。ETL 过程用于从多个源提取业务数据，清理数据，然后集成这些数据，并将它们装入数据仓库数据库中，为数据分析做好准备。ETL 过程设计尽管实际的 ETL 设计和实现在很大程度上取决于为数据仓库项目选择的 ETL 工具，但是高级的系统化 ETL 设计将有助于构建高效灵活的 ETL 过程。在深入研究数据仓库 ETL 过程的设计之前，请记住 ETL 的经验法则：“ETL 过程不应修改数据，而应该优化数据。”如果您发现需

BI项目中ETL设计与思考(转)[@more@]ETL即数据抽取（Extract）、转换（Transform）、装载（Load）的过程，它是构建数据仓库的重要环节。 ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据。ETL是BI项目重要的一个环节。通常情况下，在BI项目中ETL会花掉整个项目的1/3的时间,ETL设计的好坏直接关接到BI项目的成败。　ETL的设计分三部分：数据抽取、数据的清洗转换、数据的加载。在设计ETL的时候我们也是从这三部分出发。数据的抽取是从

-[@more@]数据挖掘和知识发现的技术、方法及应用 一幅凝固的油画 全部文章参考http://blog.csdn.net/ruixj/archive/2006/03/19/629161.aspxKeywords:data mining，Knowledge discovery in databases，DM，KDD，CRISP－DM，Internet 概念基于Internet的全球信息系统的发展使我们拥有了前所未有的丰富数据。大量信息在给人们带来方便的同时也带来了一大堆问题：第一是信息过量，难以消化；第二是信息真假难以辨识；第三是信息安全难以保证；第四是信息形式不一致，难以统一处理。数据丰富、知识贫乏已经成为一个典型问题。Data Mining（数据

-[@more@]两个表间,不存在的insert,存在地updateIF OBJECT_ID('dbo.sp_showtable_insert') IS NOT NULLBEGIN DROP PROCEDURE dbo.sp_showtable_insert IF OBJECT_ID('dbo.sp_showtable_insert') IS NOT NULL PRINT '<<< FAILED DROPPING PROCEDURE dbo.sp_showtable_insert >>>' ELSE PRINT '<<< DROPPED PROCEDURE dbo.sp_showtable_insert >>>'ENDgoSET ANSI_NULLS ONgoSET QUOTED_IDENTIFIER ONgocreate procedure [dbo].[sp_showtable_insert] @tablename1 varchar(100),

-[@more@]我们经常需要将一个表insert到另外一个表中,而大部分的字段名称都一些,这样,我们就可以使用一下的sp来实现,减少很多的工作量如将t2 insert到 t1run:sp_mapping 't1','t2'IF OBJECT_ID('dbo.sp_mapping') IS NOT NULLBEGIN DROP PROCEDURE dbo.sp_mapping IF OBJECT_ID('dbo.sp_mapping') IS NOT NULL PRINT '<<< FAILED DROPPING PROCEDURE dbo.sp_mapping >>>' ELSE PRINT '<<< DROPPED PROCEDURE dbo.sp_mapping >>>'ENDgoSET ANSI_NULLS OFFgoSET QUOTED_IDENTI

_[@more@]在sqlserver中显示表的结构比如现实表TEST1的结构就run sp_showtable 'TEST1'IF OBJECT_ID('dbo.sp_showtable') IS NOT NULLBEGIN DROP PROCEDURE dbo.sp_showtable IF OBJECT_ID('dbo.sp_showtable') IS NOT NULL PRINT '<<< FAILED DROPPING PROCEDURE dbo.sp_showtable >>>' ELSE PRINT '<<< DROPPED PROCEDURE dbo.sp_showtable >>>'ENDgoSET ANSI_NULLS ONgoSET QUOTED_IDENTIFIER ONgocreate procedure [dbo].[sp_showtable] @tablename varchar(50) as begi

显示数据库中表的主键[@more@]以下以sqlserver为例写的显示数据库中表的主键declare @objname nvarchar(50),@i int, @thiskey nvarchar(131),@keys nvarchar(2126),@indid int,@objid int CREATE TABLE #pktab ( table_name nvarchar(50), pk_name nvarchar(300) ) declare ms_crs_ind cursor local static for select a.name from sysobjects a where xtype='U' and name like 'T%' order by name open ms_crs_ind fetch ms_crs_ind into @objname while @@fetch_status >= 0 begin set @objid=object_id(@

－[@more@]在SSAS（SQL Server Analysis Services）中构建Cube和编写MDX的时候，我们很容易被一些名词弄糊涂，比如：Dimension（维度），Measures Dimension（度量维度），Measure（度量），Hierarchy（层次结构），Attribute hierarchy（属性层次结构），Level（级别），Cell（单元），Member（成员），Member Property（成员属性），Set（集），Turple（元组）等等。要想弄清楚这些名词，就必须理解Cube的结构。上述名词的解释详见：http://msdn2.microsoft.com/en-us/library/ms144884.aspxCube、Dimension和MeasureCube就象一个坐标系

Where vs. Subselect/Subcube[@more@]Where和Subselect/Subcube在MDX都是经常使用的语句，有的时候它们能起到相同的效果，而有的时候却又不能，这究竟是什么原因呢？本文将尝试就这些情况作一些分析（不对之处，欢迎大家及时指出）。以下MDX语句可以在SSAS（打了SP2补丁的版本）的示例库：Adventure Works中运行。 相同和不同Where和Subselect/Subcube都能够限定计算的范围。请看下面的两个语句：例一Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->SELECT[Measures].[Internet

MDX的上下文（Context） [@more@]我们说要构建Cube或编写MDX，就必须理解Cube的结构。可是当熟悉了Cube结构之后，我们还是会有很多困挠。比如：为何有些需求用MDX语句似乎做不出来？为何有些MDX语句无法输出我们想要的结果（不是抱错就是输出结果错误）？为何有些MDX语句执行起来非常的慢？要想解决这些问题，除了了解Cube结构，我们还必须理解MDX的运行机制，而运行机制的首要概念便是上下文(Context)。以下MDX语句可以在SSAS的示例库：Adventure Works中运行。 上下文(Context)MDX的运行机制可以用一句话来描述——在Cube结构的基础上，

本文来源于《MDX Solutions with Microsoft SQL.Server Analysis Services 2005 and Hyperion Essbase 2nd Edition》一书的内容[@more@]本文来源于《MDX Solutions with Microsoft SQL.Server Analysis Services 2005 and Hyperion Essbase 2nd Edition》一书的内容。在编写MDX中，各种各样的边界情况存在，比如：Member不存在，被0除，或则某个部分在cube和维度中并不存在等等，本文对这些情况下如何来处理做了一个小结。以下MDX语句可以在SSAS的示例库：Adventure Works中运行。 Member不存在的情况在使用Member的一些函数(比如:Lag，L

本文来源于《MDX Solutions with Microsoft SQL.Server Analysis Services 2005 and Hyperion Essbase 2nd Edition》一书的内容，主要介绍了一些经常编写的MDX语句的写法。以下MDX语句可以在SSAS的示例库[@more@]本文来源于《MDX Solutions with Microsoft SQL.Server Analysis Services 2005 and Hyperion Essbase 2nd Edition》一书的内容，主要介绍了一些经常编写的MDX语句的写法。以下MDX语句可以在SSAS的示例库：Adventure Works中运行。例子模型以下的MDX中用到的Hierarchy如下：百分比1）某个子项占总体的百分比。比如：每种Produc

建立DW2.0的相关技术和方案[@more@]DW2.0是随着信息系统架构逐步发展而产生的，它来源于很多公司信息系统架构的实际经验。在实际构建DW2.0时，尽管有着架构的蓝图，但是DW2.0的不同部件也是要逐步建立起来，即它的不同部件产生的时间是不一样的。通常DW2.0中第一个构建的部件是整合区（或者实现整合区的前几次少量的迭代过程）。整合区建立好后建立交互区。交互区之后是近线区，接着是归档区。这些不同部件的构建顺序和数据产生的生命周期的顺序是相同的。DW2.0的另一个构建顺序是先建立ODS再建立数据仓库。即先建立交互区，接着建立整合区

DW2.0中维护数据完整性和可信性的数据[@more@]DW2.0的数据来源是操作型源系统和遗留系统。对于一个企业来说，数据是最先在操作型环境中生成的。但是，这些操作型环境大多是很多年前开发的，文档记录基本上都不全。在这些系统中，数据是伴随着交易产生的，随着交易的发生，数据作为副产品被收集起来。典型的操作型环境的主要元素包括程序、报表、处理器、文件、数据库等内容。DW2.0中的数据来源于操作型环境，所以我们需要对操作型环境高度关注。进入DW2.0的数据需要准确、最新、完整。为了保证这一点，我们需要定义用什么来决定源系统的系