star-schema

7热度

1回答

OLAP数据库由非规范化形式的数据组成。这意味着数据冗余和此数据冗余有助于通过更少的连接数来检索数据，从而有助于更快地检索。但是OLAP数据库的流行设计是事实维度模型。事实表将存储数字基于事实的条目（销售数量等），而维度表将存储与该事实相关的“描述性属性”，即销售所针对的客户的详细信息。我的问题是，在这个设计中，它看起来并不是非规格化的，因为所有的维度表都有对事实表的外键引用。它与OLTP设计

0热度

1回答

数据仓库和挖掘中的模式设计

我在事实和维度表之间有点混淆，我无法清除我的疑问。事情是我必须设计一个模式，其中有一个关键字表。并且对应于每个关键字我们都有一个日期表和网站表（该关键字是为哪个网站生成的）。现在有这种情况下工作我很困惑哪些表被分配为事实和哪一个作为维表。关键字表格包含key_id和关键字名称。日期表格包含月份，年份和星期。网站表格包含关键字所属网站的名称。请向我建议此架构的架构。

0热度

2回答

我是否应该将多个客户拼合成一个维度行或使用桥接表

我是数据仓库的新手，我有一个具有合同事实表的星型模式。它拥有开始日期，结束日期，金额等基本合同信息。我必须将这些事实链接到客户维度。每份合约最多有4位顾客。所以我认为，我有两个选择要么我压平4名顾客进一行例如： DimCutomers name1, lastName1, birthDate1, ... , name4, lastName4, birthDate4 从我所听到的另一种选择是

1热度

1回答

如何在大型数据仓库中为发票创建数据模型？

我正在为大型数据仓库中的客户发票创建数据模型。下面显示了一个典型的发票中的字段：以下是数据模型我摸索出这么远的发票型号：传统的观点认为，大型数据仓库应该使用星型模式，这意味着一个事实表，但似乎是模拟一个inv oice我需要两个事实表，如上所示。使用两个事实表是否正确？

3热度

3回答

这是MySQL JOIN吗？

SELECT dim_date.date, dim_locations.city, fact_numbers.metric FROM dim_date, fact_numbers WHERE dim_date.id = fact_numbers.fk_dim_date_id AND dim_locations.city = "Toronto" AND

0热度

1回答

星型模式的缺点是什么？

在大数据的数据库设计中使用星型模式有什么缺点？是事实表的大尺寸出了问题？或者我们可以认为磁盘空间很便宜，事实表的大小不是问题呢？

1热度

1回答

用于确定唯一登录的数据集市结构

背景：我有基于星型模式结构（即事实和维度表）的数据集市。我已经掌握了确定包括日期范围，接口和区域在内的任何维度组合的用户登录次数正常计数的技巧。问题：当我尝试确定唯一登录的次数时，我陷入困境，例如，因为任何天数的登录次数不是每天唯一登录次数的总和在那一套。我的可怕的解决方案：我完全没有想法，除了存储每个单一的登录表与时间戳和用户ID。

2热度

1回答

数值属性的维表中的空值

处理维表中缺失值的最佳方法是什么？在文本列的情况下，很容易写出“NA：Missing”，但是对于保留的特定值重要的数字列应该做些什么。注意：我不希望使用绑定值的解决方案（例如，“0-50”，“50-100”，“NA：Missing”）的文本列。例如，客户维度可能具有出生年份。应该如何处理遗失的出生年份？保留它为空？添加一个任意数字作为占位符，例如1900？有时，可能很难找到占位符号码。例如，

3热度

3回答

在星型模式中我的时间维度表的属性

我正在用星型模式建模构建DW。我将用它与pentaho进行BI项目。我当然会有一个时间维度表。我将用不同的粒度（日，周，月，年或其他）来分析我的事实表我应该为每个粒度在我的维度表中放置一个属性（所以我有一天属性，一个月属性，一年的属性...）或者我应该只写日期，然后计算与此日期的所有内容（获取日期的月份，日期的年份...）？ THKS很多关于你的帮助

0热度

2回答

设计事实表以允许简单的最近检测事实类

我正在处理联系历史事实表的数据仓库事实表设计。我目前的架构看起来是这样的： [FK] DateKey INT [FK] TimeKey INT [NK] CustomerNK INT [NK] CustomerPhoneNK INT [FK] ContactTypeKey INT [FK] ContactResultKey INT [BK] ContactRefBK INT