Questions tagged «data-warehouse»

为报告（特别是汇总报告）而优化的数据库系统。通常但并非总是使用星型模式来实现。

3
数据仓库设计：组合的日期时间维度与单独的日期和时间维度和时区
我们刚刚开始为新的数据仓库设计，我们正在尝试设计日期和时间维度的工作方式。我们需要能够支持多个时区（可能至少是GMT，IST，PST和EST）。最初，我们以为我们可以将日期时间维度的组合范围缩小到15分钟左右，这样一来，事实表中就有一个键，而所有受支持时区的所有不同日期时间数据都在一个维度表中。（即日期键，GMT日期，GMT时间，IST日期，IST时间等） Kimball建议将日期维度与日期时间维度分开，以防止表格过大（数据仓库工具包第240页），听起来不错，但这意味着我们在每个时区的事实表中都有两个键我们需要支持（一个代表日期，另一个代表一天中的时间）。 由于我在这方面经验不足，所以我希望有人知道两种方法之间的权衡，即性能与所有不同时区密钥的管理。也许还有其他方法，我已经看到有人谈论每个时区在事实表中有单独的行，但是如果您的事实表有数百万行，那么您需要将其四倍以添加时区，这似乎是一个问题。 如果我们进行15分钟的粒化，那么我们的日期时间维度表中每年将有131,400（24 * 15 * 365）行，这听起来听起来并不可怕，但是直到我们测试了一些之后，我们才能确定原型查询。在事实表中具有单独的时区键的另一个问题是查询必须根据所需的时区将维度表连接到其他列，也许这是SSAS为您解决的事情，我不确定。 感谢您的任何想法，-Matt
4
在时间维度表中应该将索引放在哪里？
在阅读了该网站有关索引的问答后，我想到了一个问题。 如果使用的是时间维度表，而粒度级别较低则为日。索引应该放在哪里？ Randy Melder的问题是：“索引”在RDBMS上意味着什么？说过 ： 将索引视为“目录” ...即文件位置的指针的有序列表，又称偏移量 就时间维度而言，如果时间表存储了唯一年份的全天，则大多数数据研究可能针对特定的一天，特定的一周，特定的月份或特定的季度进行。 我的问题是：是否应该为所有这些字段设置索引？ Day被认为是唯一的，因此对于这一天，我完全理解索引的使用。但是一个星期id将发生7次，一个月id将发生30/31次，一个季度id将或多或少发生120次。 还应该为那些字段添加索引吗？ 还会有用吗？ 我问你，因为在同一问题上，大卫·斯皮利特（David Spillett）说： 当然，添加过多的索引可能是一个糟糕的优化，因为用于存储索引的额外空间（如果您的DB看到许多写操作，则还有用于维护索引的IO负载）可能比最优读取请求稍差一些，这是一个更糟糕的问题。 ，所以不要过度操作。 那么，对于时间维度情况，最好的考虑因素是什么？
2
星型架构和数据立方体之间的区别？
我参与了一个新项目，其中我必须从现有的关系数据库系统中创建数据多维数据集。 我了解到，现有系统的设计不正确，我不确定从哪里开始。 我的问题是： Star Schema和数据立方体之间有什么区别？ 我必须从哪里开始？从星型模式还是直接从数据多维数据集？ 数据立方体是从星形模式生成的吗？ 我在关系数据建模方面经验不足，这个问题似乎太基本了，我试图从很少的资源中弄清楚，但仍不清楚。请给出您的意见和建议？ 如果我错过了与此问题相关的非常重要的事情，请也分享您的想法。
3
什么时候应该删除索引并重新创建？
我们正在构建一个最初将是1 TB的数据仓库，并且每月将增长20gig。 对于某些表，我们每天进行ETL流程，而另一些表则每周/每月进行。 当有数据导入到表中时，是否有必要删除并重新创建索引？ 是否有必要删除和重新创建索引，或者它们会自动更新？ 统计信息设置为自动更新。 非常感谢您的帮助和指导。 我得到了这个天才脚本： SELECT 'ALTER INDEX [' + ix.name + '] ON [' + s.name + '].[' + t.name + '] ' + CASE WHEN ps.avg_fragmentation_in_percent > 40 THEN 'REBUILD' ELSE 'REORGANIZE' END + CASE WHEN pc.partition_count > 1 THEN ' PARTITION = ' + …
3
事实表外键为空？
我是数据集市设计的新手，需要清除一些概念。 我已经阅读了一些有关维建模的知识，在该模型中，事实表存储了对维表的外键引用。 现在假设我有一个电话号码维度表和一个phone_extension维度表。（这些表具有不同的详细信息，因此我无法将它们组合在一起） 据我了解，这两个维度表都将具有整数主键以获得更好的性能，事实表将具有其自己的整数主键，并且还存储对这些维度表的外键引用。 但是，假设我有一种情况，并非所有电话号码都有与之相关的phone_extension。（某些电话号码不需要加分机号） 对于具有扩展名的电话号码，事实表将同时具有两个维表的外键引用，但是如何捕获只有电话号码却没有扩展名的情况（反之亦然，即没有电话号码的扩展名） ？ 我是否应该使用事实表中电话号码为FK且具有值且phone_extension外键为null的方式捕获此类信息？还是这些无关的对象没有记录在事实表中？ 我还需要生成此数据集市的报告。那么，我是从查询事实表并检索维键值开始还是直接从维表中报告？ 感谢您阅读本文的时间！！ 感谢任何帮助！
1
“累积快照”事实表中的“测量类型尺寸”
我有一个累积的快照事实表，该表跟踪终端中容器的进入和退出。 容器可以以3种不同的方式进入和退出，因此我想创建一个特定的尺寸表，其中列出了这3种可能的方式（火车，轮船或卡车）。 然后我读了这篇文章，基本上说这种技术是错误的，但我不明白为什么。 第一篇文章： 有时，当事实表的一长串事实稀疏地填充在任何单独的行中时，它很想创建一个度量类型维度，以将事实表行折叠为由度量类型维度标识的单个通用事实。我们通常不建议这种方法。尽管它删除了所有空的事实列，但将事实表的大小乘以每行中已占用列的平均数，这使列内计算更加困难。当潜在事实的数量极高（数百个）时，此技术是可以接受的，但对于任何给定的事实表行，只有极少数适用。 我了解，如果为事务事实表实现了“ 度量类型维 ”，则可能会产生其他文章所述的问题，但是如果用于累积快照事实，我看不到任何不利之处。 第二篇文章：（ 实现“度量类型维”的一些缺点） [...]如果我们使用“度量类型维”，我们将失去这种分析能力。如果一项措施与其他措施不兼容，我们将无法将其相加。 [...]我们的SQL运行以生成报告所需的传递次数越多，报告就越慢。 [...]在BI工具上，如果不放置度量类型过滤器，则可能会使用户冒着“垃圾信息”的危险。从可用性的角度来看，这种设计是垃圾。 对Mark Storey-Smith的回答 非常好的方法，我永远也不会想到。 另一件事：将集装箱带入码头的车辆的每次进出都有唯一的ID，该ID向我提供其他信息，例如：车辆的预计到达，实际到达，如果是码头的船只，如果是卡车，收费站以及许多其他信息... 这是3个不同的事实表，它们必须以某种方式链接到容器事实表。 我以为航行的ID是degenerate dimension，因此它将直接进入容器事实表。因此，我的疑问是：我应该在容器事实表中添加6个不同的字段（vessel_voyage_in_key，vessel_voyage_out_key，train_voyage_in_key，train_voyage_out_key，truck_voyage_in_key，truck_voyage_out_key）还是仅动态链接到各个表的其他2个字段（voyage_in，voyage_out）？ 希望我的疑问很清楚，谢谢。
3
数据仓库服务器。您如何计算RAM / CPU规格？
我正在尝试为我们计划的数据仓库升级编写数据仓库服务器的规范。 在VMWare主机上运行虚拟服务器时，我们可以根据需要添加或删除资源。过去，我们根据需要逐渐增加了RAM和CPU。随着需求的增加，我们游说了更多的资源。（主要是磁盘和RAM）。 我们要求更多。他们给了我们尽可能少的东西。 但是最近，每当我们谈论资源时，我们都因一开始就没有正确配置机器而受到批评，现在我被告知开发主机已被用尽，没有可用的RAM。 我们是一个小型的地方政府组织，拥有约50个DW常规用户。在正常的日常使用中，它运行良好。我们获得了良好的mdx查询性能，并且我们的报告和仪表板速度很快。用户感到高兴。 但是，我们的ETL流程会整夜运行，并且当同时处理数据集市时，我们开始看到内存不足的迹象。昨晚SSIS失败，并发出有关“内存不足错误”的警告。 我们现有的DW服务器是Win 2008 R2，具有4个CPU和16Gb RAM，运行SQL 2012 Std。我将最大服务器内存设置为12GB，为OS和服务等保留了4GB。我们现有的DW有3个数据集市/ OLAP多维数据集，并且我们还在开发2个。 +----------+----------+---------------+-----------+---------------+ | Datamart | Files GB | Fact (Rows) | Fact (Mb) | ETL & Process | | OLAP cube| | | | Time (hours) | +----------+----------+---------------+-----------+---------------+ | PBI | 3 | 190,000 | 180 | 0.2 …
1
填充日期维度表的最佳方法
我正在寻找在SQL Server 2008数据库中填充日期维度表的方法。表中的字段如下： [DateId] INT IDENTITY(1,1) PRIMARY KEY [DateTime] DATETIME [Date] DATE [DayOfWeek_Number] TINYINT [DayOfWeek_Name] VARCHAR(9) [DayOfWeek_ShortName] VARCHAR(3) [Week_Number] TINYINT [Fiscal_DayOfMonth] TINYINT [Fiscal_Month_Number] TINYINT [Fiscal_Month_Name] VARCHAR(12) [Fiscal_Month_ShortName] VARCHAR(3) [Fiscal_Quarter] TINYINT [Fiscal_Year] INT [Calendar_DayOfMonth] TINYINT [Calendar_Month Number] TINYINT [Calendar_Month_Name] VARCHAR(9) [Calendar_Month_ShortName] VARCHAR(3) [Calendar_Quarter] TINYINT [Calendar_Year] INT [IsLeapYear] BIT [IsWeekDay] BIT [IsWeekend] …
3
更新大复制维度（SQL Server PDW）
我们将SQL Server PDW设备用于我们的数据仓库。我们仓库中的表之一是具有约2000万行的复制表。作为ETL流程的一部分，我们需要使该维度的旧记录过期；但是，我们看到更新少数记录（<100）需要1个小时以上才能完成。如果可以的话，这就是我想要改进的地方。 自然，我想到的一个选择就是将“维度”从“复制”更改为“分布式”。我的测试表明，这将解决ETL过程花费很长时间（从1.5个小时降低到30秒）的问题，但是针对此维度的分布式版本的所有联接都将受到影响，因为联接几乎从未基于同一分布柱。当我查看其中一些查询的执行计划时，通常会看到ShuffleMove或BroadcastMove操作。 因此，我对PDW专家的问题是： 为了提高在此Dimension 的复制版本中更新记录的性能，是否可以做其他事情？ 再一次，移动到分布式表似乎不是最好的解决方案，因为它会影响其他人开发的数百个已编写的SQL查询和报告。
1
同一实体的维度和事实？
我是DW设计的新手，正在研究DW以对某些IT基础结构进行建模。 此时的主要问题/问题是如何对驱动器信息进行建模。 我们将在文件和文件夹上收集汇总数据，并在物理驱动器上收集单独的数据。驱动器信息将至少包括总空间和可用空间，并将每周更新几次。 需要回答的业务问题之一是驱动器使用率随时间变化的趋势。该驱动器信息还将用于向下到文件/文件夹级别的层次结构中。 我现在可以看到的选项是： 实施DRIVE为维度 简化层次结构设计 这会导致报告问题吗？仅在一个维度上报告有时间限制的数据对我来说似乎违反直觉 拥有一个维度，每次刷新数据时您都会知道，这似乎也有问题 实施DRIVE为事实表 简化报告 使层次结构复杂化（？）-我还将Drive用来将数据映射回特定的服务器或计算机。可以将事实表用作层次结构中的中间级别吗？我认为不是。 实施DRIVE既是事实和维度 事实将只包含密钥，日期和空间事实 维度将包括其他非累加数据，例如所用的计算机等。 似乎可以解决这两个问题，但这是一种反模式吗？
2
SQL Server 2012数据仓库和不同版本
使用Sql Server 2012，有3个旗舰版本：企业版，商业智能，标准版。 两者之间的完整比较：http : //www.microsoft.com/sqlserver/en/us/future-editions/sql2012-editions.aspx 商业智能版暗示它的目的是用于数据仓库，并涵盖了似乎最关键的问题： 自助式商业智能（警报，Power View，SharePoint Server的PowerPivot） 先进的企业BI（表格BI语义模型，高级分析和报告，VertiPaq™内存引擎） 高级数据集成（模糊分组和查找，更改数据捕获，高级数据挖掘） 企业数据管理（数据质量服务，主数据服务） 但是，企业版是唯一具有以下功能的版本： 数据仓库（列存储索引，压缩，分区） BI和Enterprise版本之间需要分开哪些功能？
3
有关大型SQL Server数据库设计的建议
我们正在MSSQL 2008 R2 Standard中创建一个数据库，该数据库将存储大量记录。我们每年在一张表中估计有2亿多条记录，而我们主要是在插入数据时很少进行UPDATE或DELETE操作。它是一个数据存档系统，我们每天都在其中插入历史记录。我们将根据用户要求在此历史记录上生成不同类型的报告，因此我们有些顾虑，需要技术投入和建议。 管理此类存档表和数据库的最佳方法是什么？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.