随笔分类 - BI
BI开发，cube操作等
摘要：MDX : Non Empty v/s NonEmptyUser Rating:/50PoorBestWritten by Jason Thomas Friday, 07 May 2010 00:44Reposted fromJason Thomas blogwith the author's pe...
阅读全文
摘要：数据集结元数据：数据需要的信息：数据传输计划和特殊的传输结果；数据传送区的文件用法，包括持续时间消耗的所有者信息维度表管理：规范化维度的定义和规范化事实的定义；关联job的规范，剥除域，查找属性；降低每一个引入描述属性维度规则的变化速度，每一个生产键所分配的当前代理键，也包括在内存中执行映射的查找表；前一天生产维度的复本，作为比较差异基础；换换和聚合：数据清洗规范；数据增加和映射转换；为数据挖掘所准备的数据转换；目标计划设计，源和目标数据流，和目标所有权；数据库管理系统的导入脚本；聚合定义；聚合用法统计，基础数据表使用统计，以及潜在的聚合；聚合更改日记；审计，工作日志和文档：数据沿袭和审计记录
阅读全文
摘要：装载数据仓库过程中，不管作业是实时执行还是批处理方式执行，其调度时间，执行顺序和执行环境都是关键点。本章描述创建一个ETL操作策略，来保证数据仓库的数据即时可用。ETL执行策略分为两种：1 调度 2 支持（为了确保etl过程运行完成，数据仓库必须能够被监控活动情况，并且必须有人专门支持）调度工具：任何企业数据仓库都必须拥有一个健壮的企业级ETL调度机制。主流的ETL供应商都提供其核心的ETL引擎提供打包的调度器ETL调度器必须的功能：1 令牌识别（ETL如何知道外部源的数据文件已经达到并开始其处理过程？ETL系统必须能够识别文件已经在文件系统中存在，并自动开始执行，这个过程叫做令牌识别）令牌是
阅读全文
摘要：要进入开发阶段，了解不同的ETL产品。整个ETL系统中，时间或更精确的，吞吐量是主要关心的内容。这种转换处理任务设计的主要目的归根结底是使得数据装载到展现表中最快并使得最终用户能快速的从这些表中得到响应。推或者拉：推，是源系统主动把文件推向ETL服务器，拉是ETL服务器主动从文件服务器上抽取文件。无论是推拉都得保证数据没有错误，传输完成，确保传输完全的一个简单的标志是使用标志（信号）文件。标志仅仅表示它相关的文件的可读性。预装载中的数据排序源数据在数据库中的时候，排序很容易通过数据库，查询数据的order by来实现，但是如果源数据来自平面文件，那么开始ETL处理之前需要一个排序的程序：在主机
阅读全文
摘要：实事表的基本结构每一个事实表通过表的粒度来定义。粒度必须按照现实的，物理的意义来定义，然后考虑纬度和事实表中的其他字段等因素。所有的事实表包含了一组关联到维表的外建，而这些维表提供了事实表度量的上下文。如果设计的时候没有给与足够的注意，那么就有可能违反事实表上主见的假设，可能在同一时段两个同样的度量事件会发生，但是数据仓库团队没有意识到这一点，显然，每个事实表应该拥有一个主建，即使仅仅是出于管理的需要也应该在事实表上设立主见。如果没有主键完整性，那么事实表中有可能存在两个或者更多一样的记录，而且没有办法按照独立的量测事件来区分他们。确保参照完整性在维度模型中可能有两种情况会导致违反参照完整性：
阅读全文
摘要：维度的基础框架主键是指包含一个无意义的，唯一标识数字的字段，数据仓库拥有这些代理键值但并不把他赋给任何实体。维度的主键主要用于连接事实表。因为所有事实表必须保持表的参照完整性，因此维表中的主键连接的字段就称为事实表的外键。（大多数关系型数据库维表和事实表通过单一字段连接获得最大性能，当外键是数字类型的时候事实表是最为紧凑的）维表将其他的一个或者多个字段组成维表的自然键（natural key），自然键是源系统抽取的有意义的字段。比如employeeID。当维表是静态的，不随时间而变化，那么代理键和自然键就是一一对应的关系。后续有缓慢变化的维度，那么每个自然键就有多个代理键，以记录维度信息的历史
阅读全文
摘要：清洗和规范化实际上真正的改变了数据，并对数据能否用于预期的目标起到决定作用。会有三个表：数据评估报告，错误事件事实表，审计维。清洗和规范化步骤中产生元数据。四个部分：1 设计目标 2 清洗提交 3 快照及其度量 4 规范化提交清洗和规范化过程中关注的更多的是约束关系与控制而不是数据上的内容。提交阶段，主要会介绍清洗子系统的主要结构：错误事件表和审计维定义数据质量：正确的，明确的，一致的，完整的（每个实例定义了特定的值和描述，要确保总数量是完整的）有两个里程碑：1 是在数据抽取完毕之后 2 是在数据清理和规范化之后1 设计目标 参与者： 数据仓库管理员（日常决策），信息驾驶员（定义信息策略，..
阅读全文
摘要：初始化加载数据，捕获源数据中的数据内容的变化不重要。但是加载完成后，捕获源系统中的数据变化立即变成非常重要的任务。要提前规划这个任务。必须制定相应的策略来在项目中捕获源数据中不断增长的变化。几种捕获源数据变化的方法：使用审计列：审计列示附在每个表的最后用来存储记录增加或者修改的日期或者时间，审计列一般通过数据库触发器产生，当插入或更新记录的时候自动生成（有时候为了提升性能，这些列由前端产生）。确认审计列是可靠的，则需要制定策略来利用他们，比如：比较每个记录最后修改的日期和时间与上次加载后的最后的日期和时间，取他们中较晚的值。由于事实表和维表可以来源于许多不同的表和系统，并且由于事实表只包含外建
阅读全文
摘要：数据不同形式，可以通过ODBC连接不同的数据源，ODBC灵活性是以性能为代价的。对于那些通过ODBC处理数据的ETL过程，在ETL系统和后台数据库之间增加了两层：ODBC管理器，ODBC驱动程序主机数据源：有特定的结构加强外围设备通道来处理输入输出，CPU可以专注处理数据，比如计算和均衡。如果源数据在主机系统上，则ETL工具具有从EBCDIC到ASCII的数据转换功能是很重要，如果可能，最好是在主机上进行转换以避免发生任何教小数值的和压缩数字的损失，如果通过磁带或者其他的介质获取，则这种转换必须由非主机环境中的ETL工具来实现。（具体不详细说了，这块接触的不多）平面文件：使用平面文件的原因 1
阅读全文
摘要：在开始创建抽取系统之前，需要一份逻辑数据映射，它描述了那些提交到前台的表中原始字段和最终目标字段之间的关系。该文档贯穿ETL系统物理之前设计逻辑：1 有一个规划 2确定候选的数据源 3使用数据评估分析工具分析源系统 4 接受数据线和业务规则的遍历 5充分理解数据仓库数据模型 6 验证计算和公式的有效性逻辑数据映射的组成：目标表名称，表类型，SCD(缓慢变化维度),源数据库，源表名称，源列名称，转换。这个表必须清洗的描述在转换的过程中包含的流程，不能有任何疑问的地方。表类型给了我们数据加载过程执行的次序--》先是维表，然后是事实表。与表类型一起，加载维表过程SCD类型很重要，开发之前需要理解哪些
阅读全文
摘要：数据仓库的后台部分经常被称为：集结区（StagingArea）。数据集结主要是指写入磁盘。并且建议ETL的四个主要检查点都要有数据集结。是将数据存储在物理集结区还是在内存中直接处理，这个问题是ETL架构中的最根本的选择之一。开发的ETL处理的效率很大程度上取决于能否很好的均衡物理IO与内存处理。能够在把数据写入集结表和保持在内存两种方法取得理想的均衡是个很大的挑战，也是优化处理过程中必须考虑的问题。最终目标：将数据以最快的速度从数据源获取到最终目标；在处理的过程发生错误的时候，能够进行恢复而无需从头开始。如果计划在内存中处理所有的ETL数据处理，不要忘记任何一种数据仓库，无论其架构和运行环境如
阅读全文
摘要：ETL系统能够：消除数据错误并纠正缺失数据；提供对于数据可信度的文档化衡量；为保护数据获取相互作用的数据流程；把多个源数据整合到一起；将数据进行结构化供最终用户使用。抽取转换加载==〉抽取，清洗，规格化，提交。创建ETL系统的时候，头脑里并存的两条主线：规划&设计主线 和 数据流主线规划&设计主线 ：需求和实现===〉架构===〉系统实施===〉测试和发布数据流主线 ：抽取===〉清洗====〉规格化====〉提交架构的时候，我们必须作出关于创建ETL系统创建方法的主要的决定，其中包括：1 手工编码还是使用ETL工具 2批处理还是流数据处理 3水平任务依赖还是垂直任务依赖4自动
阅读全文
摘要：declare @set nvarchar(max),@sql nvarchar(max)declare@tablenew table(a float,b float,c float,d float,e float,f float,g float,h float,k float,i float)set @set=''select @set=@set+'['+calendar.LedgerPeriod+'],' from parameter cross join calendar where(parameter.year*100+parameter
阅读全文
摘要：如果要保证cube在处理的时候，能够顺利的从二维数据库中加载的到数据，那么就必须得保证 事实表 和维表能够在二维数据库那块查询的时候 能够匹配的上。 也就是说，事实表和每一个维表 在left join的时候务必能够检索的到数据。 但实际上这块容易出的问题就是： 事实表中有的数据，维表中没有这些数据 ，比如说 事实表的一个网元纬度 有名字为AAA的网元，而网元维表并没有这个AAA的成员。 ...
阅读全文
摘要：cube中会有很多度量值组，实际是每个度量值组对应一个相应的事实表。因此在不同的度量值组查询度量值的时候，速度不如在同一个度量值组里面查询的效率高。 度量值组对应的维表会跟相应的事实表进行关联。 同时，Cube中还有很多引用的度量值组，引用的度量值组引用过来之后，他们依旧会和原来的维表进行关联。 度量值组只能引用一次，不能引用多次，比如 一个cube中的度量值组全部是引用过来的，...
阅读全文
摘要：(1) ssas的solution只保存了各个表等信息之间的关系.内部并不存在对应的数据,而真正的数据都存储在下面的文件夹的 data文件夹中.可以打开查看具体的信息. 而config文件中对应的是 数据库的属性信息,一般不要进行修改 (2) cube 对应的solution 是最初用于构建cube用的，他必须部署之后才会产生具体的影响。 但是用solution修改cube相...
阅读全文
摘要：应该一般保证每个分区的数据的数目不大于两千万，大于两千万 数据就会访问比较慢 分区会一般根据时间进行分区，一般都需要保证每个分区的数量差不多，而比如对城市进行分区，那么可能信息并不相同，进而导致每个分区的数量不同。 设计度量值的时候可以有很多选项，比如说就MAX的值或者其他的，就是为了以后聚合使用的，后面设计聚合的时候 一般会对城市或者时间设计百分之百的聚合，为了提高查询的效...
阅读全文
摘要：星形架构每个纬度表利用纬度关键字通过事实表中的外键约束于事实表中的某一行，实现与事实表的关联，这就要求事实表中的外键不能为空，这与一般数据库中外键允许为空是不同的。这种结构就使得用户能够很容易的从纬度表中的数据分析开始，获得纬度的关键字，以便连接到中心的事实表，进行查询，这样就减少了在事实表中扫描的数据量，以提高查询性能。雪花型架构纬度表除了具有星形模式中的纬度表的功能之外，还连接对事实表进行详细描述的详细类别表，详细类别表通过对事实表在有关纬度上的详细描述达到了缩小事实表和提高查询的目的。数据仓库数据集市数据集市就是面向不同主题的，一个主题对应自己的一个表，他和数据仓库的不同实际上就是数据仓
阅读全文
摘要：事务处理和分析处理的对比事务处理OLTP分析处理OLAP处理个别记录关注一般趋势高生产率（每天数百万事务处理记录）低生产率（每天只有少数操作）系统的操作可以改变数据系统的操作可以回答问题查询只涉及几条记录查询经常波及整个数据库许多操作更改源数据大多数操作是只读的需要完全时时更新经常批量跟新（晚上或者周末）能很快的反映新数据最终反映新数据olap 数据较之optp数据要多一步数据多维化或者预综合处理，建立不同级别的统计数据，从而满足快速统计分析和查询的要求前端访问的方式不同：olap采用多维报表和统计图形，查询提出以及数据输入直观灵活，用户可以方便的逐层细化，切块，切片，数据旋转。oltp则是固
阅读全文
摘要：与其他 Microsoft .NET Framework 数据访问接口一样，ADOMD.NET 也用作应用程序与数据源之间的桥梁。 但 ADOMD.NET 与其他 .NET Framework 数据访问接口的不同之处在于 ADOMD.NET 处理的是分析数据。 为了处理分析数据，ADOMD.NET 支持的功能与其他 .NET Framework 数据访问接口所支持的功能差异很大。 ADOMD...
阅读全文
浙公网安备 33010602011771号