我们刚刚开始设计一个新的数据仓库，我们正在尝试设计日期和时间维度的工作方式。我们需要能够支持多个时区（可能至少是 GMT、IST、PST 和 EST）。我们最初认为我们将有一个广泛的组合日期时间维度，大约 15 分钟的粒度，这样我们的事实表中有一个键，所有支持的时区的所有不同日期时间数据都在一个维度表中。（即日期键、GMT 日期、GMT 时间、IST 日期、IST 时间等...）
Kimball 建议从一天的时间维度中设置一个单独的日期维度，以防止表变得过大（数据仓库工具包第 240 页），这听起来不错，但这意味着我们在每个时区的事实表中有两个键我们需要支持（一个用于日期，一个用于一天中的时间）。
由于我在这方面非常缺乏经验，我希望有人知道这两种方法之间的权衡，即性能与所有不同时区键的管理。也许还有其他方法，我看到有些人谈论在每个时区的事实表中有一个单独的行，但这似乎是一个问题，如果你的事实表有数百万行，那么你需要将它翻两番来添加时区.
如果我们使用 15 分钟的粒度，我们的日期时间维度表中每年将有 131,400 (24 * 15 * 365) 行，这对性能来说听起来并不太可怕，但在我们测试之前我们不会确定原型查询。在事实表中使用单独的时区键的另一个问题是查询必须根据所需的时区将维度表连接到不同的列，也许这是 SSAS 为您处理的事情，我不确定.
感谢您的任何想法，-马特
我们正在构建一个最初为 1 TB 的数据仓库，并将每月增长约 20gigs。
对于某些表，我们每天都在执行 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 = ' + cast(ps.partition_number as nvarchar(max)) ELSE '' END
FROM sys.indexes AS ix INNER JOIN sys.tables t
ON t.object_id = ix.object_id
INNER JOIN sys.schemas s
ON t.schema_id = …我们正在扩展我们的数据库服务器。我想知道我们应该如何计算我们的数据库需要多少硬件资源？
以下是有关我们当前数据库服务器的一些信息：
ibdata1和 56 GB 没有它.
use information_schema;
select VARIABLE_VALUE into @num_queries from GLOBAL_STATUS where VARIABLE_NAME = 'QUESTIONS';
select VARIABLE_VALUE into @uptime …我正在与一位同事合作，他建议将我们的 1 个实例数据库拆分为大约 7 个数据库（按数据域划分）用于开发和 7 个相同的数据库用于生产。我得到了测试生产二元性逻辑，但是在什么情况下或将我们的 1 个相对简单的数据库拆分为 7 个数据库有什么优势？我们的数据仓库仅由一个商业智能应用程序消耗/使用，期间。
我很关心这个方向，所以希望你能讨论提出这个拆分的一般原因，我可以给你一个数据库当前属性的概要。
1 个数据库数据仓库：总共 352 GB，203 个表，170 个视图
建议拆分：
A: 280 GB
B: 43 GB
C: 28 GB
D: 1 GB
E,F,G: < 1 GB combined
正如您所看到的，就提议的好处而言，这已经是一个令人头疼的问题，因为存储甚至不会远程平均分配，80% 还留在 1 个数据库上。显然，按架构对我们的数据库进行分区是不可能的（从硬件角度来看），因为我们没有企业级 SQL Server。
给出的拆分原因：
我的菜鸟想法：这些问题不是和数据库拆分无关吗？它们只是需要以任何方式自行解决的问题。
我的想法：在我看来，这似乎并不大。
我的想法： .... 这对我来说似乎完全荒谬，但也许我错了。我们已经按照 13 个“源系统”模式组织了我们的数据仓库。
-- 这个问题不是也和多数据库完全无关吗？我的理解是死锁发生在表级别（实际上通常甚至只是行级别，但是呃）。即便如此，我们所有的数据插入都发生在午夜，我们所有下游到 BI 的选择发生在凌晨 2 点。让两个进程更新同一个表与多个数据库无关，是不是（死锁会发生）？另外，我个人没有看到在正常操作期间发生表死锁的证据。
只有我们两个人在数据库上工作。他有可能真的想隔离我们的“封地”。真的，这不是问题，但无论如何不能在架构级别确定用户权限吗？
将数据仓库拆分为多个数据库的正当理由是什么？
很想在这里进一步了解一般的数据库。是的，我碰巧在我的知识空白处做了很多工作，但这份工作就是它，我一直在努力。到目前为止，东西一直很好用（敲木头）。
Sql Server 2012 有 3 个旗舰版：企业版、商业智能版、标准版。
三者的完整对比：http : //www.microsoft.com/sqlserver/en/us/future-editions/sql2012-editions.aspx
商业智能版本暗示它的目的是用于数据仓库，并涵盖了似乎是关键问题：
但是，企业版是唯一具有以下功能的版本：
数据仓库（列存储索引、压缩、分区）
这需要什么功能在 BI 和企业版之间分开？
我是 DW 设计的新手，正在研究 DW 以对某些 IT 基础架构进行建模。
此时的主要问题/问题是如何对驱动信息建模。
我们将收集文件和文件夹的汇总数据，以及物理驱动器上的单独数据。驱动器信息将至少包括总空间和可用空间，并且每周更新数次。
需要回答的业务问题之一是驱动器的使用随时间的变化趋势如何。驱动器信息也将用于向下到文件/文件夹级别的层次结构中。
我现在可以看到的选项是：
DRIVE作为维度 实施
DRIVE作为事实表实施
Drive将数据映射回特定的服务器或计算机。可以将事实表用作层次结构中的中间级别吗？我不认为是。实施DRIVE既是事实和维度
我希望在 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] BIT
[IsWorkday] BIT
[IsHoliday] BIT
[HolidayName] VARCHAR(255)
我编写了一个函数 DateListInRange(D1,D2)，它返回两个参数日期 D1 和 D2 之间的所有日期。
IE。参数“2014-01-01”和“2014-01-03”将返回：
2014-01-01
2014-01-02
2014-01-03
我想为一个范围内的所有日期填充 DATE_DIM 表，即 2010-01-01 到 2020-01-01。大多数字段都可以用 SQL 2008 DATEPART、DATENAME 和 YEAR …
sql-server-2008 data-warehouse business-intelligence dimension star-schema
我正在尝试为我们计划的数据仓库升级编写数据仓库服务器的规范。
当我们在 VMWare 主机上运行虚拟服务器时，我们能够根据需要添加或删除资源。过去，我们根据需要逐步添加 RAM 和 CPU。随着我们需求的增加，我们已经游说获得更多资源。（主要是磁盘和 RAM）。
我们要求更多。他们给我们尽可能少。
然而，最近每当我们谈论资源时，我们都会因为没有首先正确指定机器而受到批评，现在我被告知开发主机已用完，没有更多可用的 RAM。
我们是一个小型的地方政府组织，拥有约 50 名 DW 的常规用户。在正常的日常使用中，它运行良好。我们获得了良好的 mdx 查询性能，并且我们的报告和仪表板速度很快。用户很高兴。
然而，我们的 ETL 过程整夜运行，当同时处理数据集市时，我们开始看到内存压力的迹象。昨晚 SSIS 因“内存不足错误”的警告而失败。
我们现有的 DW 服务器是 Win 2008 R2，带有 4 个 CPU 和 16Gb 的 RAM，运行 SQL 2012 Std。我将最大服务器内存设置为 12GB，为操作系统和服务等留出 4GB。我们现有的 DW 有 3 个数据集市/OLAP 多维数据集，我们正在开发另外 2 个。
+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB | Fact (Rows) | Fact (Mb) | ETL & Process |
| OLAP cube| | | | Time (hours) |
+----------+----------+---------------+-----------+---------------+
| PBI | …我有一个累积快照事实表，用于跟踪终端中容器的进入和退出。
集装箱可以通过3 种不同的方式进出，所以我想创建一个特定的维度表，列出这 3 种可能的方式（火车、船只或卡车）。
然后我读了这篇文章，它基本上说这种技术是错误的，但我不明白为什么。
第一篇：
有时，当事实表有一长列事实且在任何单个行中都稀疏填充时，很容易创建一个度量类型维度，将事实表行折叠为由度量类型维度标识的单个通用事实。我们一般不推荐这种方法。虽然它删除了所有空的事实列，但它将事实表的大小乘以每行中被占用的平均列数，这使得列内计算变得更加困难。当潜在事实的数量非常多（数百个）时，此技术是可以接受的，但适用于任何给定事实表行的数量并不多。
我知道如果为事务事实表实现了“度量类型维度”，它可能会产生像另一篇文章所说的那样的问题，但如果用于累积快照事实，我看不出任何缺点。
第二篇文章：（ 实施“度量类型维度”的一些缺点）
- [...] 如果我们使用“度量类型维度”，我们将失去这种分析能力。如果一个度量与其他度量不兼容，我们就无法将它们相加。
- [...] 我们的 SQL 生成报告需要运行的传递次数越多，报告的速度就越慢。
- [...] 在 BI 工具上，如果您不放置度量类型过滤器，您就有可能让用户获得“垃圾信息”。从可用性的角度来看，这种设计是垃圾。
非常好的方法，我从来没有想过。
另一件事：将集装箱带入码头的车辆的每次进出都有一个唯一的 ID，它为我提供了其他信息，例如：车辆的预计到达时间、实际到达时间、如果是船只、码头、卡车、收费站和许多其他信息...
这是 3 个不同的事实表，它们必须以某种方式链接到容器事实表。
我以为航程的ID是a 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）？
我希望我的疑问很清楚，谢谢。
这是一个关于数据仓库设计的问题。我们正在建立一个医疗保健数据仓库，并从 2 个主要的源系统开始，这些系统结合了大约 20,000 个表和 2 TB 的数据。1) 它是高维数据 2) 我们不想严重影响 OLTP 系统
我们选择了增量 Kimball 设计。我的问题是，是否应该暂存所有数据，然后将其分类为插入/更新并放入数据仓库。然后会为下一次增量加载清除暂存数据。
这为您留下了 1 个数据副本。
另一种方法是将其增量加载到暂存中，将其分类为插入/更新，并以与源系统相同的格式存储它。然后我们将来自源系统的数据从完整副本合并到数据仓库中。
这基本上会给您留下 2 个数据副本，一个以源系统的形式存在，另一个加载到实际的数据仓库中。
这方面的最佳做法是什么？我原本认为最好只将副本存储在数据仓库中，并在每次加载时清除源表。
但是，在这种情况下，如果您不得不返回现有维度并添加一列，则必须重新加载所有相关源表。加上你会失去历史？
不过，将它存储两次似乎效率很低……只是想对设计、您的经验和最佳实践有一些想法。
data-warehouse ×10
sql-server ×5
dimension ×2
architecture ×1
hardware ×1
mysql ×1
scalability ×1
ssas ×1
ssis ×1
star-schema ×1